maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/unittests/ADT/TripleTest.cpp

947 lines
32 KiB
C++
Raw Normal View History

Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
//===----------- Triple.cpp - Triple unit tests ---------------------------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "gtest/gtest.h"
#include "llvm/ADT/Triple.h"
using namespace llvm;
namespace {
TEST(TripleTest, BasicParsing) {
Triple T;
T = Triple("");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("", T.getArchName().str());
EXPECT_EQ("", T.getVendorName().str());
EXPECT_EQ("", T.getOSName().str());
EXPECT_EQ("", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("-");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("", T.getArchName().str());
EXPECT_EQ("", T.getVendorName().str());
EXPECT_EQ("", T.getOSName().str());
EXPECT_EQ("", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("--");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("", T.getArchName().str());
EXPECT_EQ("", T.getVendorName().str());
EXPECT_EQ("", T.getOSName().str());
EXPECT_EQ("", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("---");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("", T.getArchName().str());
EXPECT_EQ("", T.getVendorName().str());
EXPECT_EQ("", T.getOSName().str());
EXPECT_EQ("", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("----");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("", T.getArchName().str());
EXPECT_EQ("", T.getVendorName().str());
EXPECT_EQ("", T.getOSName().str());
EXPECT_EQ("-", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("a");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("a", T.getArchName().str());
EXPECT_EQ("", T.getVendorName().str());
EXPECT_EQ("", T.getOSName().str());
EXPECT_EQ("", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("a-b");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("a", T.getArchName().str());
EXPECT_EQ("b", T.getVendorName().str());
EXPECT_EQ("", T.getOSName().str());
EXPECT_EQ("", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("a-b-c");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("a", T.getArchName().str());
EXPECT_EQ("b", T.getVendorName().str());
EXPECT_EQ("c", T.getOSName().str());
EXPECT_EQ("", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("a-b-c-d");
Update Triple to use StringRef/Twine based APIs. - This is now shorter, simpler, safer, and more efficient, what a deal. llvm-svn: 77119
2009-07-26 11:31:47 +08:00
EXPECT_EQ("a", T.getArchName().str());
EXPECT_EQ("b", T.getVendorName().str());
EXPECT_EQ("c", T.getOSName().str());
EXPECT_EQ("d", T.getEnvironmentName().str());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
}
TEST(TripleTest, ParsedIDs) {
Triple T;
T = Triple("i386-apple-darwin");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::Apple, T.getVendor());
EXPECT_EQ(Triple::Darwin, T.getOS());
Add better support for environment portion of triple. Original patch by Cameron Esfahani, tweaked to use array_lengthof. llvm-svn: 114073
2010-09-16 16:25:48 +08:00
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("x86_64-pc-linux-gnu");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::x86_64, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
Clang was not parsing target triples involving EABI and was generating wrong IR (wrong PCS) and passing the wrong information down llc via the target-triple printed in IR. I've fixed this by adding the parsing of EABI into LLVM's Triple class and using it to choose the correct PCS in Clang's Tools. A Clang patch is on its way to use this infrastructure. llvm-svn: 123990
2011-01-22 02:25:47 +08:00
EXPECT_EQ(Triple::GNU, T.getEnvironment());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
Add triple support for the IBM BG/P and BG/Q supercomputers. llvm-svn: 153882
2012-04-03 02:31:33 +08:00
T = Triple("powerpc-bgp-linux");
EXPECT_EQ(Triple::ppc, T.getArch());
EXPECT_EQ(Triple::BGP, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("powerpc-bgp-cnk");
EXPECT_EQ(Triple::ppc, T.getArch());
EXPECT_EQ(Triple::BGP, T.getVendor());
EXPECT_EQ(Triple::CNK, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("powerpc64-bgq-linux");
EXPECT_EQ(Triple::ppc64, T.getArch());
EXPECT_EQ(Triple::BGQ, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Add powerpc-ibm-aix to Triple. Patch by Kai. llvm-svn: 165792
2012-10-12 19:08:57 +08:00
T = Triple("powerpc-ibm-aix");
EXPECT_EQ(Triple::ppc, T.getArch());
EXPECT_EQ(Triple::IBM, T.getVendor());
EXPECT_EQ(Triple::AIX, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("powerpc64-ibm-aix");
EXPECT_EQ(Triple::ppc64, T.getArch());
EXPECT_EQ(Triple::IBM, T.getVendor());
EXPECT_EQ(Triple::AIX, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("powerpc-dunno-notsure");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::ppc, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
Add better support for environment portion of triple. Original patch by Cameron Esfahani, tweaked to use array_lengthof. llvm-svn: 114073
2010-09-16 16:25:48 +08:00
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
Remove NoVendor and NoOS, added in commit 123990, from Triple. While it may be useful to understand "none", this is not the place for it. Tweak the fix to Normalize while there: the fix added in 123990 works correctly, but I like this way better. Finally, now that Triple understands some non-trivial environment values, teach the unittests about them. llvm-svn: 124720
2011-02-02 18:08:38 +08:00
T = Triple("arm-none-none-eabi");
Clang was not parsing target triples involving EABI and was generating wrong IR (wrong PCS) and passing the wrong information down llc via the target-triple printed in IR. I've fixed this by adding the parsing of EABI into LLVM's Triple class and using it to choose the correct PCS in Clang's Tools. A Clang patch is on its way to use this infrastructure. llvm-svn: 123990
2011-01-22 02:25:47 +08:00
EXPECT_EQ(Triple::arm, T.getArch());
Remove NoVendor and NoOS, added in commit 123990, from Triple. While it may be useful to understand "none", this is not the place for it. Tweak the fix to Normalize while there: the fix added in 123990 works correctly, but I like this way better. Finally, now that Triple understands some non-trivial environment values, teach the unittests about them. llvm-svn: 124720
2011-02-02 18:08:38 +08:00
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
Clang was not parsing target triples involving EABI and was generating wrong IR (wrong PCS) and passing the wrong information down llc via the target-triple printed in IR. I've fixed this by adding the parsing of EABI into LLVM's Triple class and using it to choose the correct PCS in Clang's Tools. A Clang patch is on its way to use this infrastructure. llvm-svn: 123990
2011-01-22 02:25:47 +08:00
EXPECT_EQ(Triple::EABI, T.getEnvironment());
Fix regression in parsing armv{6,7}hl- triples. These are used by SUSE and Redhat currently. Reviewed by Jonathan Roelofs. llvm-svn: 236492
2015-05-05 17:29:43 +08:00
T = Triple("armv6hl-none-linux-gnueabi");
EXPECT_EQ(Triple::arm, T.getArch());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUEABI, T.getEnvironment());
T = Triple("armv7hl-none-linux-gnueabi");
EXPECT_EQ(Triple::arm, T.getArch());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUEABI, T.getEnvironment());
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
T = Triple("amdil-unknown-unknown");
EXPECT_EQ(Triple::amdil, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
T = Triple("amdil64-unknown-unknown");
EXPECT_EQ(Triple::amdil64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
T = Triple("hsail-unknown-unknown");
EXPECT_EQ(Triple::hsail, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
T = Triple("hsail64-unknown-unknown");
EXPECT_EQ(Triple::hsail64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
New architecture name - 'sparcel' for Sparc little-endian. Differential Revision: http://reviews.llvm.org/D9263 llvm-svn: 236139
2015-04-30 03:15:08 +08:00
T = Triple("sparcel-unknown-unknown");
EXPECT_EQ(Triple::sparcel, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
T = Triple("spir-unknown-unknown");
EXPECT_EQ(Triple::spir, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
T = Triple("spir64-unknown-unknown");
EXPECT_EQ(Triple::spir64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
Add support for Nuxi CloudABI. CloudABI is a POSIX-like runtime environment built around the concept of capability-based security. More details: https://github.com/NuxiNL/cloudlibc CloudABI uses its own ELFOSABI number. This number has been allocated by the maintainers of ELF a couple of days ago. Reviewed by: echristo llvm-svn: 231681
2015-03-10 02:40:45 +08:00
T = Triple("x86_64-unknown-cloudabi");
EXPECT_EQ(Triple::x86_64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::CloudABI, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T = Triple("huh");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::UnknownArch, T.getArch());
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
}
Improve Triple to recognize the OS in i386-mingw32. llvm-svn: 79359
2009-08-19 03:26:55 +08:00
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
static std::string Join(StringRef A, StringRef B, StringRef C) {
std::string Str = A; Str += '-'; Str += B; Str += '-'; Str += C;
return Str;
}
Improve Triple to recognize the OS in i386-mingw32. llvm-svn: 79359
2009-08-19 03:26:55 +08:00
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
static std::string Join(StringRef A, StringRef B, StringRef C, StringRef D) {
std::string Str = A; Str += '-'; Str += B; Str += '-'; Str += C; Str += '-';
Str += D; return Str;
}
Improve Triple to recognize the OS in i386-mingw32. llvm-svn: 79359
2009-08-19 03:26:55 +08:00
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
TEST(TripleTest, Normalization) {
Clang was not parsing target triples involving EABI and was generating wrong IR (wrong PCS) and passing the wrong information down llc via the target-triple printed in IR. I've fixed this by adding the parsing of EABI into LLVM's Triple class and using it to choose the correct PCS in Clang's Tools. A Clang patch is on its way to use this infrastructure. llvm-svn: 123990
2011-01-22 02:25:47 +08:00
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
EXPECT_EQ("", Triple::normalize(""));
EXPECT_EQ("-", Triple::normalize("-"));
EXPECT_EQ("--", Triple::normalize("--"));
EXPECT_EQ("---", Triple::normalize("---"));
EXPECT_EQ("----", Triple::normalize("----"));
EXPECT_EQ("a", Triple::normalize("a"));
EXPECT_EQ("a-b", Triple::normalize("a-b"));
EXPECT_EQ("a-b-c", Triple::normalize("a-b-c"));
EXPECT_EQ("a-b-c-d", Triple::normalize("a-b-c-d"));
EXPECT_EQ("i386-b-c", Triple::normalize("i386-b-c"));
EXPECT_EQ("i386-a-c", Triple::normalize("a-i386-c"));
EXPECT_EQ("i386-a-b", Triple::normalize("a-b-i386"));
Add better support for environment portion of triple. Original patch by Cameron Esfahani, tweaked to use array_lengthof. llvm-svn: 114073
2010-09-16 16:25:48 +08:00
EXPECT_EQ("i386-a-b-c", Triple::normalize("a-b-c-i386"));
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
EXPECT_EQ("a-pc-c", Triple::normalize("a-pc-c"));
EXPECT_EQ("-pc-b-c", Triple::normalize("pc-b-c"));
EXPECT_EQ("a-pc-b", Triple::normalize("a-b-pc"));
Add better support for environment portion of triple. Original patch by Cameron Esfahani, tweaked to use array_lengthof. llvm-svn: 114073
2010-09-16 16:25:48 +08:00
EXPECT_EQ("a-pc-b-c", Triple::normalize("a-b-c-pc"));
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
EXPECT_EQ("a-b-linux", Triple::normalize("a-b-linux"));
EXPECT_EQ("--linux-b-c", Triple::normalize("linux-b-c"));
EXPECT_EQ("a--linux-c", Triple::normalize("a-linux-c"));
EXPECT_EQ("i386-pc-a", Triple::normalize("a-pc-i386"));
EXPECT_EQ("i386-pc-", Triple::normalize("-pc-i386"));
EXPECT_EQ("-pc-linux-c", Triple::normalize("linux-pc-c"));
EXPECT_EQ("-pc-linux", Triple::normalize("linux-pc-"));
EXPECT_EQ("i386", Triple::normalize("i386"));
EXPECT_EQ("-pc", Triple::normalize("pc"));
EXPECT_EQ("--linux", Triple::normalize("linux"));
Clang was not parsing target triples involving EABI and was generating wrong IR (wrong PCS) and passing the wrong information down llc via the target-triple printed in IR. I've fixed this by adding the parsing of EABI into LLVM's Triple class and using it to choose the correct PCS in Clang's Tools. A Clang patch is on its way to use this infrastructure. llvm-svn: 123990
2011-01-22 02:25:47 +08:00
EXPECT_EQ("x86_64--linux-gnu", Triple::normalize("x86_64-gnu-linux"));
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
// Check that normalizing a permutated set of valid components returns a
// triple with the unpermuted components.
StringRef C[4];
Exhaustively test all triples in TripleTest. Iteration over all permutations didn't really work, due to evolution of the underlying enums. Differential Revision: http://reviews.llvm.org/D9057 llvm-svn: 236251
2015-05-01 04:08:44 +08:00
for (int Arch = 1+Triple::UnknownArch; Arch <= Triple::LastArchType; ++Arch) {
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
C[0] = Triple::getArchTypeName(Triple::ArchType(Arch));
Exhaustively test all triples in TripleTest. Iteration over all permutations didn't really work, due to evolution of the underlying enums. Differential Revision: http://reviews.llvm.org/D9057 llvm-svn: 236251
2015-05-01 04:08:44 +08:00
for (int Vendor = 1+Triple::UnknownVendor; Vendor <= Triple::LastVendorType;
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
++Vendor) {
C[1] = Triple::getVendorTypeName(Triple::VendorType(Vendor));
Exhaustively test all triples in TripleTest. Iteration over all permutations didn't really work, due to evolution of the underlying enums. Differential Revision: http://reviews.llvm.org/D9057 llvm-svn: 236251
2015-05-01 04:08:44 +08:00
for (int OS = 1+Triple::UnknownOS; OS <= Triple::LastOSType; ++OS) {
ADT: remove MinGW32 and Cygwin OSType enum Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
2014-08-10 07:12:20 +08:00
if (OS == Triple::Win32)
Canonicalise Windows target triple spellings Construct a uniform Windows target triple nomenclature which is congruent to the Linux counterpart. The old triples are normalised to the new canonical form. This cleans up the long-standing issue of odd naming for various Windows environments. There are four different environments on Windows: MSVC: The MS ABI, MSVCRT environment as defined by Microsoft GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries Itanium: The MSVCRT environment + libc++ built with Itanium ABI Cygnus: The Cygwin environment which uses custom libraries for everything The following spellings are now written as: i686-pc-win32 => i686-pc-windows-msvc i686-pc-mingw32 => i686-pc-windows-gnu i686-pc-cygwin => i686-pc-windows-cygnus This should be sufficiently flexible to allow us to target other windows environments in the future as necessary. llvm-svn: 204977
2014-03-28 06:50:05 +08:00
continue;
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
C[2] = Triple::getOSTypeName(Triple::OSType(OS));
Part of this test is invariant inside the inner loop - move it outside the loop. llvm-svn: 124784
2011-02-03 16:14:04 +08:00
std::string E = Join(C[0], C[1], C[2]);
EXPECT_EQ(E, Triple::normalize(Join(C[0], C[1], C[2])));
EXPECT_EQ(E, Triple::normalize(Join(C[0], C[2], C[1])));
EXPECT_EQ(E, Triple::normalize(Join(C[1], C[2], C[0])));
EXPECT_EQ(E, Triple::normalize(Join(C[1], C[0], C[2])));
EXPECT_EQ(E, Triple::normalize(Join(C[2], C[0], C[1])));
EXPECT_EQ(E, Triple::normalize(Join(C[2], C[1], C[0])));
Exhaustively test all triples in TripleTest. Iteration over all permutations didn't really work, due to evolution of the underlying enums. Differential Revision: http://reviews.llvm.org/D9057 llvm-svn: 236251
2015-05-01 04:08:44 +08:00
for (int Env = 1 + Triple::UnknownEnvironment; Env <= Triple::LastEnvironmentType;
Remove NoVendor and NoOS, added in commit 123990, from Triple. While it may be useful to understand "none", this is not the place for it. Tweak the fix to Normalize while there: the fix added in 123990 works correctly, but I like this way better. Finally, now that Triple understands some non-trivial environment values, teach the unittests about them. llvm-svn: 124720
2011-02-02 18:08:38 +08:00
++Env) {
C[3] = Triple::getEnvironmentTypeName(Triple::EnvironmentType(Env));
std::string F = Join(C[0], C[1], C[2], C[3]);
EXPECT_EQ(F, Triple::normalize(Join(C[0], C[1], C[2], C[3])));
EXPECT_EQ(F, Triple::normalize(Join(C[0], C[1], C[3], C[2])));
EXPECT_EQ(F, Triple::normalize(Join(C[0], C[2], C[3], C[1])));
EXPECT_EQ(F, Triple::normalize(Join(C[0], C[2], C[1], C[3])));
EXPECT_EQ(F, Triple::normalize(Join(C[0], C[3], C[1], C[2])));
EXPECT_EQ(F, Triple::normalize(Join(C[0], C[3], C[2], C[1])));
EXPECT_EQ(F, Triple::normalize(Join(C[1], C[2], C[3], C[0])));
EXPECT_EQ(F, Triple::normalize(Join(C[1], C[2], C[0], C[3])));
EXPECT_EQ(F, Triple::normalize(Join(C[1], C[3], C[0], C[2])));
EXPECT_EQ(F, Triple::normalize(Join(C[1], C[3], C[2], C[0])));
EXPECT_EQ(F, Triple::normalize(Join(C[1], C[0], C[2], C[3])));
EXPECT_EQ(F, Triple::normalize(Join(C[1], C[0], C[3], C[2])));
EXPECT_EQ(F, Triple::normalize(Join(C[2], C[3], C[0], C[1])));
EXPECT_EQ(F, Triple::normalize(Join(C[2], C[3], C[1], C[0])));
EXPECT_EQ(F, Triple::normalize(Join(C[2], C[0], C[1], C[3])));
EXPECT_EQ(F, Triple::normalize(Join(C[2], C[0], C[3], C[1])));
EXPECT_EQ(F, Triple::normalize(Join(C[2], C[1], C[3], C[0])));
EXPECT_EQ(F, Triple::normalize(Join(C[2], C[1], C[0], C[3])));
EXPECT_EQ(F, Triple::normalize(Join(C[3], C[0], C[1], C[2])));
EXPECT_EQ(F, Triple::normalize(Join(C[3], C[0], C[2], C[1])));
EXPECT_EQ(F, Triple::normalize(Join(C[3], C[1], C[2], C[0])));
EXPECT_EQ(F, Triple::normalize(Join(C[3], C[1], C[0], C[2])));
EXPECT_EQ(F, Triple::normalize(Join(C[3], C[2], C[0], C[1])));
EXPECT_EQ(F, Triple::normalize(Join(C[3], C[2], C[1], C[0])));
}
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
}
}
}
// Various real-world funky triples. The value returned by GCC's config.sub
// is given in the comment.
Canonicalise Windows target triple spellings Construct a uniform Windows target triple nomenclature which is congruent to the Linux counterpart. The old triples are normalised to the new canonical form. This cleans up the long-standing issue of odd naming for various Windows environments. There are four different environments on Windows: MSVC: The MS ABI, MSVCRT environment as defined by Microsoft GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries Itanium: The MSVCRT environment + libc++ built with Itanium ABI Cygnus: The Cygwin environment which uses custom libraries for everything The following spellings are now written as: i686-pc-win32 => i686-pc-windows-msvc i686-pc-mingw32 => i686-pc-windows-gnu i686-pc-cygwin => i686-pc-windows-cygnus This should be sufficiently flexible to allow us to target other windows environments in the future as necessary. llvm-svn: 204977
2014-03-28 06:50:05 +08:00
EXPECT_EQ("i386--windows-gnu", Triple::normalize("i386-mingw32")); // i386-pc-mingw32
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
EXPECT_EQ("x86_64--linux-gnu", Triple::normalize("x86_64-linux-gnu")); // x86_64-pc-linux-gnu
EXPECT_EQ("i486--linux-gnu", Triple::normalize("i486-linux-gnu")); // i486-pc-linux-gnu
EXPECT_EQ("i386-redhat-linux", Triple::normalize("i386-redhat-linux")); // i386-redhat-linux-gnu
EXPECT_EQ("i686--linux", Triple::normalize("i686-linux")); // i686-pc-linux-gnu
Remove NoVendor and NoOS, added in commit 123990, from Triple. While it may be useful to understand "none", this is not the place for it. Tweak the fix to Normalize while there: the fix added in 123990 works correctly, but I like this way better. Finally, now that Triple understands some non-trivial environment values, teach the unittests about them. llvm-svn: 124720
2011-02-02 18:08:38 +08:00
EXPECT_EQ("arm-none--eabi", Triple::normalize("arm-none-eabi")); // arm-none-eabi
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
}
TEST(TripleTest, MutateName) {
Triple T;
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::UnknownArch, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
Add better support for environment portion of triple. Original patch by Cameron Esfahani, tweaked to use array_lengthof. llvm-svn: 114073
2010-09-16 16:25:48 +08:00
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T.setArchName("i386");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ("i386--", T.getTriple());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T.setVendorName("pc");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ("i386-pc-", T.getTriple());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T.setOSName("linux");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ("i386-pc-linux", T.getTriple());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T.setEnvironmentName("gnu");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ("i386-pc-linux-gnu", T.getTriple());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T.setOSName("freebsd");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::FreeBSD, T.getOS());
EXPECT_EQ("i386-pc-freebsd-gnu", T.getTriple());
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
T.setOSAndEnvironmentName("darwin");
Reversed order of args in EXPECT_EQ() macros to be in the correct order: EXPECT_EQ(expected, actual) . This will make error messages understandable as it uses terms such as "expected" and "actual" based on the order of arguments. llvm-svn: 73150
2009-06-10 05:48:57 +08:00
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::Darwin, T.getOS());
EXPECT_EQ("i386-pc-darwin", T.getTriple());
Clang was not parsing target triples involving EABI and was generating wrong IR (wrong PCS) and passing the wrong information down llc via the target-triple printed in IR. I've fixed this by adding the parsing of EABI into LLVM's Triple class and using it to choose the correct PCS in Clang's Tools. A Clang patch is on its way to use this infrastructure. llvm-svn: 123990
2011-01-22 02:25:47 +08:00
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
}
Add various coarse bit-width architecture predicates to llvm::Triple. These are very useful for frontends and other utilities reasoning about or selecting between triples. llvm-svn: 149353
2012-01-31 12:52:32 +08:00
TEST(TripleTest, BitWidthPredicates) {
Triple T;
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::arm);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::hexagon);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::mips);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::mips64);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
T.setArch(Triple::msp430);
EXPECT_TRUE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::ppc);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::ppc64);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
T.setArch(Triple::x86);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::x86_64);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
T.setArch(Triple::amdil);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::amdil64);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
T.setArch(Triple::hsail);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::hsail64);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
T.setArch(Triple::spir);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::spir64);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
New architecture name - 'sparcel' for Sparc little-endian. Differential Revision: http://reviews.llvm.org/D9263 llvm-svn: 236139
2015-04-30 03:15:08 +08:00
T.setArch(Triple::sparc);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::sparcel);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::sparcv9);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
Add various coarse bit-width architecture predicates to llvm::Triple. These are very useful for frontends and other utilities reasoning about or selecting between triples. llvm-svn: 149353
2012-01-31 12:52:32 +08:00
}
Introduce helpers to compute the 32-bit varaints and 64-bit variants of some architectures. These are useful for interacting with multiarch or bi-arch GCC (or GCC-based) toolchains. llvm-svn: 149895
2012-02-07 04:46:33 +08:00
TEST(TripleTest, BitWidthArchVariants) {
Triple T;
EXPECT_EQ(Triple::UnknownArch, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, T.get64BitArchVariant().getArch());
T.setArch(Triple::UnknownArch);
EXPECT_EQ(Triple::UnknownArch, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, T.get64BitArchVariant().getArch());
T.setArch(Triple::mips);
EXPECT_EQ(Triple::mips, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::mips64, T.get64BitArchVariant().getArch());
T.setArch(Triple::mipsel);
EXPECT_EQ(Triple::mipsel, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::mips64el, T.get64BitArchVariant().getArch());
T.setArch(Triple::ppc);
EXPECT_EQ(Triple::ppc, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::ppc64, T.get64BitArchVariant().getArch());
Remove the PTX back-end and all of its artifacts (triple, etc.) This back-end was deprecated in favor of the NVPTX back-end. NV_CONTRIB llvm-svn: 157417
2012-05-25 05:38:21 +08:00
T.setArch(Triple::nvptx);
EXPECT_EQ(Triple::nvptx, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::nvptx64, T.get64BitArchVariant().getArch());
Introduce helpers to compute the 32-bit varaints and 64-bit variants of some architectures. These are useful for interacting with multiarch or bi-arch GCC (or GCC-based) toolchains. llvm-svn: 149895
2012-02-07 04:46:33 +08:00
T.setArch(Triple::sparc);
EXPECT_EQ(Triple::sparc, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::sparcv9, T.get64BitArchVariant().getArch());
T.setArch(Triple::x86);
EXPECT_EQ(Triple::x86, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::x86_64, T.get64BitArchVariant().getArch());
T.setArch(Triple::mips64);
EXPECT_EQ(Triple::mips, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::mips64, T.get64BitArchVariant().getArch());
T.setArch(Triple::mips64el);
EXPECT_EQ(Triple::mipsel, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::mips64el, T.get64BitArchVariant().getArch());
T.setArch(Triple::ppc64);
EXPECT_EQ(Triple::ppc, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::ppc64, T.get64BitArchVariant().getArch());
Remove the PTX back-end and all of its artifacts (triple, etc.) This back-end was deprecated in favor of the NVPTX back-end. NV_CONTRIB llvm-svn: 157417
2012-05-25 05:38:21 +08:00
T.setArch(Triple::nvptx64);
EXPECT_EQ(Triple::nvptx, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::nvptx64, T.get64BitArchVariant().getArch());
Introduce helpers to compute the 32-bit varaints and 64-bit variants of some architectures. These are useful for interacting with multiarch or bi-arch GCC (or GCC-based) toolchains. llvm-svn: 149895
2012-02-07 04:46:33 +08:00
T.setArch(Triple::sparcv9);
EXPECT_EQ(Triple::sparc, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::sparcv9, T.get64BitArchVariant().getArch());
T.setArch(Triple::x86_64);
EXPECT_EQ(Triple::x86, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::x86_64, T.get64BitArchVariant().getArch());
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
T.setArch(Triple::amdil);
EXPECT_EQ(Triple::amdil, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::amdil64, T.get64BitArchVariant().getArch());
T.setArch(Triple::amdil64);
EXPECT_EQ(Triple::amdil, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::amdil64, T.get64BitArchVariant().getArch());
T.setArch(Triple::hsail);
EXPECT_EQ(Triple::hsail, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::hsail64, T.get64BitArchVariant().getArch());
T.setArch(Triple::hsail64);
EXPECT_EQ(Triple::hsail, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::hsail64, T.get64BitArchVariant().getArch());
T.setArch(Triple::spir);
EXPECT_EQ(Triple::spir, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::spir64, T.get64BitArchVariant().getArch());
T.setArch(Triple::spir64);
EXPECT_EQ(Triple::spir, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::spir64, T.get64BitArchVariant().getArch());
Introduce helpers to compute the 32-bit varaints and 64-bit variants of some architectures. These are useful for interacting with multiarch or bi-arch GCC (or GCC-based) toolchains. llvm-svn: 149895
2012-02-07 04:46:33 +08:00
}
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
TEST(TripleTest, getOSVersion) {
Triple T;
unsigned Major, Minor, Micro;
T = Triple("i386-apple-darwin9");
Added a unit test for r173983 that verifies that Target.isiOS() works correctly. As a bonus I put in some extra checks to make sure that we are identifying the machine word of various Mac OS X/iOS targets appropriately. llvm-svn: 173994
2013-01-31 07:48:13 +08:00
EXPECT_TRUE(T.isMacOSX());
EXPECT_FALSE(T.isiOS());
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
T.getMacOSXVersion(Major, Minor, Micro);
EXPECT_EQ((unsigned)10, Major);
EXPECT_EQ((unsigned)5, Minor);
EXPECT_EQ((unsigned)0, Micro);
T.getiOSVersion(Major, Minor, Micro);
Darwin: update default iOS version to 5.0 Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful option and can give surprising results (like tail calls being disabled). 5.0 seems like a reasonable compromise as a platform that's still interesting to some people. rdar://problem/15567348 llvm-svn: 196912
2013-12-10 19:53:16 +08:00
EXPECT_EQ((unsigned)5, Major);
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
EXPECT_EQ((unsigned)0, Minor);
EXPECT_EQ((unsigned)0, Micro);
T = Triple("x86_64-apple-darwin9");
Added a unit test for r173983 that verifies that Target.isiOS() works correctly. As a bonus I put in some extra checks to make sure that we are identifying the machine word of various Mac OS X/iOS targets appropriately. llvm-svn: 173994
2013-01-31 07:48:13 +08:00
EXPECT_TRUE(T.isMacOSX());
EXPECT_FALSE(T.isiOS());
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
T.getMacOSXVersion(Major, Minor, Micro);
EXPECT_EQ((unsigned)10, Major);
EXPECT_EQ((unsigned)5, Minor);
EXPECT_EQ((unsigned)0, Micro);
T.getiOSVersion(Major, Minor, Micro);
Darwin: update default iOS version to 5.0 Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful option and can give surprising results (like tail calls being disabled). 5.0 seems like a reasonable compromise as a platform that's still interesting to some people. rdar://problem/15567348 llvm-svn: 196912
2013-12-10 19:53:16 +08:00
EXPECT_EQ((unsigned)5, Major);
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
EXPECT_EQ((unsigned)0, Minor);
EXPECT_EQ((unsigned)0, Micro);
T = Triple("x86_64-apple-macosx");
Added a unit test for r173983 that verifies that Target.isiOS() works correctly. As a bonus I put in some extra checks to make sure that we are identifying the machine word of various Mac OS X/iOS targets appropriately. llvm-svn: 173994
2013-01-31 07:48:13 +08:00
EXPECT_TRUE(T.isMacOSX());
EXPECT_FALSE(T.isiOS());
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
T.getMacOSXVersion(Major, Minor, Micro);
EXPECT_EQ((unsigned)10, Major);
EXPECT_EQ((unsigned)4, Minor);
EXPECT_EQ((unsigned)0, Micro);
T.getiOSVersion(Major, Minor, Micro);
Darwin: update default iOS version to 5.0 Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful option and can give surprising results (like tail calls being disabled). 5.0 seems like a reasonable compromise as a platform that's still interesting to some people. rdar://problem/15567348 llvm-svn: 196912
2013-12-10 19:53:16 +08:00
EXPECT_EQ((unsigned)5, Major);
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
EXPECT_EQ((unsigned)0, Minor);
EXPECT_EQ((unsigned)0, Micro);
T = Triple("x86_64-apple-macosx10.7");
Added a unit test for r173983 that verifies that Target.isiOS() works correctly. As a bonus I put in some extra checks to make sure that we are identifying the machine word of various Mac OS X/iOS targets appropriately. llvm-svn: 173994
2013-01-31 07:48:13 +08:00
EXPECT_TRUE(T.isMacOSX());
EXPECT_FALSE(T.isiOS());
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
T.getMacOSXVersion(Major, Minor, Micro);
EXPECT_EQ((unsigned)10, Major);
EXPECT_EQ((unsigned)7, Minor);
EXPECT_EQ((unsigned)0, Micro);
T.getiOSVersion(Major, Minor, Micro);
Darwin: update default iOS version to 5.0 Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful option and can give surprising results (like tail calls being disabled). 5.0 seems like a reasonable compromise as a platform that's still interesting to some people. rdar://problem/15567348 llvm-svn: 196912
2013-12-10 19:53:16 +08:00
EXPECT_EQ((unsigned)5, Major);
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
EXPECT_EQ((unsigned)0, Minor);
EXPECT_EQ((unsigned)0, Micro);
T = Triple("armv7-apple-ios");
Added a unit test for r173983 that verifies that Target.isiOS() works correctly. As a bonus I put in some extra checks to make sure that we are identifying the machine word of various Mac OS X/iOS targets appropriately. llvm-svn: 173994
2013-01-31 07:48:13 +08:00
EXPECT_FALSE(T.isMacOSX());
EXPECT_TRUE(T.isiOS());
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
T.getMacOSXVersion(Major, Minor, Micro);
EXPECT_EQ((unsigned)10, Major);
EXPECT_EQ((unsigned)4, Minor);
EXPECT_EQ((unsigned)0, Micro);
T.getiOSVersion(Major, Minor, Micro);
Darwin: update default iOS version to 5.0 Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful option and can give surprising results (like tail calls being disabled). 5.0 seems like a reasonable compromise as a platform that's still interesting to some people. rdar://problem/15567348 llvm-svn: 196912
2013-12-10 19:53:16 +08:00
EXPECT_EQ((unsigned)5, Major);
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
EXPECT_EQ((unsigned)0, Minor);
EXPECT_EQ((unsigned)0, Micro);
Darwin: update default iOS version to 5.0 Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful option and can give surprising results (like tail calls being disabled). 5.0 seems like a reasonable compromise as a platform that's still interesting to some people. rdar://problem/15567348 llvm-svn: 196912
2013-12-10 19:53:16 +08:00
T = Triple("armv7-apple-ios7.0");
Added a unit test for r173983 that verifies that Target.isiOS() works correctly. As a bonus I put in some extra checks to make sure that we are identifying the machine word of various Mac OS X/iOS targets appropriately. llvm-svn: 173994
2013-01-31 07:48:13 +08:00
EXPECT_FALSE(T.isMacOSX());
EXPECT_TRUE(T.isiOS());
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
T.getMacOSXVersion(Major, Minor, Micro);
EXPECT_EQ((unsigned)10, Major);
EXPECT_EQ((unsigned)4, Minor);
EXPECT_EQ((unsigned)0, Micro);
T.getiOSVersion(Major, Minor, Micro);
Darwin: update default iOS version to 5.0 Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful option and can give surprising results (like tail calls being disabled). 5.0 seems like a reasonable compromise as a platform that's still interesting to some people. rdar://problem/15567348 llvm-svn: 196912
2013-12-10 19:53:16 +08:00
EXPECT_EQ((unsigned)7, Major);
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +08:00
EXPECT_EQ((unsigned)0, Minor);
EXPECT_EQ((unsigned)0, Micro);
}
Support: split object format out of environment This is a preliminary setup change to support a renaming of Windows target triples. Split the object file format information out of the environment into a separate entity. Unfortunately, file format was previously treated as an environment with an unknown OS. This is most obvious in the ARM subtarget where the handling for macho on an arbitrary platform switches to AAPCS rather than APCS (as per Apple's needs). llvm-svn: 203160
2014-03-07 04:47:11 +08:00
TEST(TripleTest, FileFormat) {
EXPECT_EQ(Triple::ELF, Triple("i686-unknown-linux-gnu").getObjectFormat());
EXPECT_EQ(Triple::ELF, Triple("i686-unknown-freebsd").getObjectFormat());
EXPECT_EQ(Triple::ELF, Triple("i686-unknown-netbsd").getObjectFormat());
EXPECT_EQ(Triple::ELF, Triple("i686--win32-elf").getObjectFormat());
EXPECT_EQ(Triple::ELF, Triple("i686---elf").getObjectFormat());
EXPECT_EQ(Triple::MachO, Triple("i686-apple-macosx").getObjectFormat());
EXPECT_EQ(Triple::MachO, Triple("i686-apple-ios").getObjectFormat());
EXPECT_EQ(Triple::MachO, Triple("i686---macho").getObjectFormat());
EXPECT_EQ(Triple::COFF, Triple("i686--win32").getObjectFormat());
Support: correct Windows normalisation If the environment is unknown and no object file is provided, then assume an "MSVC" environment, otherwise, set the environment to the object file format. In the case that we have a known environment but a non-native file format for Windows (COFF) which is used for MCJIT, then append the custom file format to the triple as an additional component. This fixes the MCJIT tests on Windows. llvm-svn: 205130
2014-03-30 15:19:31 +08:00
EXPECT_EQ(Triple::ELF, Triple("i686-pc-windows-msvc-elf").getObjectFormat());
Support: generalise object type handling for Windows This generalises the object file type parsing to all Windows environments. This is used by cygwin as well as MSVC environments for MCJIT. This also makes the triple more similar to Chandler's suggestion of a separate field for the object file format. llvm-svn: 205219
2014-04-01 00:34:41 +08:00
EXPECT_EQ(Triple::ELF, Triple("i686-pc-cygwin-elf").getObjectFormat());
Support: correct Windows normalisation If the environment is unknown and no object file is provided, then assume an "MSVC" environment, otherwise, set the environment to the object file format. In the case that we have a known environment but a non-native file format for Windows (COFF) which is used for MCJIT, then append the custom file format to the triple as an additional component. This fixes the MCJIT tests on Windows. llvm-svn: 205130
2014-03-30 15:19:31 +08:00
Support: generalise object type handling for Windows This generalises the object file type parsing to all Windows environments. This is used by cygwin as well as MSVC environments for MCJIT. This also makes the triple more similar to Chandler's suggestion of a separate field for the object file format. llvm-svn: 205219
2014-04-01 00:34:41 +08:00
Triple MSVCNormalized(Triple::normalize("i686-pc-windows-msvc-elf"));
EXPECT_EQ(Triple::ELF, MSVCNormalized.getObjectFormat());
Triple GNUWindowsNormalized(Triple::normalize("i686-pc-windows-gnu-elf"));
EXPECT_EQ(Triple::ELF, GNUWindowsNormalized.getObjectFormat());
Triple CygnusNormalised(Triple::normalize("i686-pc-windows-cygnus-elf"));
EXPECT_EQ(Triple::ELF, CygnusNormalised.getObjectFormat());
Triple CygwinNormalized(Triple::normalize("i686-pc-cygwin-elf"));
EXPECT_EQ(Triple::ELF, CygwinNormalized.getObjectFormat());
Support: correct Windows normalisation If the environment is unknown and no object file is provided, then assume an "MSVC" environment, otherwise, set the environment to the object file format. In the case that we have a known environment but a non-native file format for Windows (COFF) which is used for MCJIT, then append the custom file format to the triple as an additional component. This fixes the MCJIT tests on Windows. llvm-svn: 205130
2014-03-30 15:19:31 +08:00
Support: split object format out of environment This is a preliminary setup change to support a renaming of Windows target triples. Split the object file format information out of the environment into a separate entity. Unfortunately, file format was previously treated as an environment with an unknown OS. This is most obvious in the ARM subtarget where the handling for macho on an arbitrary platform switches to AAPCS rather than APCS (as per Apple's needs). llvm-svn: 203160
2014-03-07 04:47:11 +08:00
Triple T = Triple("");
T.setObjectFormat(Triple::ELF);
EXPECT_EQ(Triple::ELF, T.getObjectFormat());
}
Canonicalise Windows target triple spellings Construct a uniform Windows target triple nomenclature which is congruent to the Linux counterpart. The old triples are normalised to the new canonical form. This cleans up the long-standing issue of odd naming for various Windows environments. There are four different environments on Windows: MSVC: The MS ABI, MSVCRT environment as defined by Microsoft GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries Itanium: The MSVCRT environment + libc++ built with Itanium ABI Cygnus: The Cygwin environment which uses custom libraries for everything The following spellings are now written as: i686-pc-win32 => i686-pc-windows-msvc i686-pc-mingw32 => i686-pc-windows-gnu i686-pc-cygwin => i686-pc-windows-cygnus This should be sufficiently flexible to allow us to target other windows environments in the future as necessary. llvm-svn: 204977
2014-03-28 06:50:05 +08:00
TEST(TripleTest, NormalizeWindows) {
EXPECT_EQ("i686-pc-windows-msvc", Triple::normalize("i686-pc-win32"));
EXPECT_EQ("i686--windows-msvc", Triple::normalize("i686-win32"));
EXPECT_EQ("i686-pc-windows-gnu", Triple::normalize("i686-pc-mingw32"));
EXPECT_EQ("i686--windows-gnu", Triple::normalize("i686-mingw32"));
EXPECT_EQ("i686-pc-windows-gnu", Triple::normalize("i686-pc-mingw32-w64"));
EXPECT_EQ("i686--windows-gnu", Triple::normalize("i686-mingw32-w64"));
EXPECT_EQ("i686-pc-windows-cygnus", Triple::normalize("i686-pc-cygwin"));
EXPECT_EQ("i686--windows-cygnus", Triple::normalize("i686-cygwin"));
EXPECT_EQ("x86_64-pc-windows-msvc", Triple::normalize("x86_64-pc-win32"));
EXPECT_EQ("x86_64--windows-msvc", Triple::normalize("x86_64-win32"));
EXPECT_EQ("x86_64-pc-windows-gnu", Triple::normalize("x86_64-pc-mingw32"));
EXPECT_EQ("x86_64--windows-gnu", Triple::normalize("x86_64-mingw32"));
EXPECT_EQ("x86_64-pc-windows-gnu", Triple::normalize("x86_64-pc-mingw32-w64"));
EXPECT_EQ("x86_64--windows-gnu", Triple::normalize("x86_64-mingw32-w64"));
EXPECT_EQ("i686-pc-windows-elf", Triple::normalize("i686-pc-win32-elf"));
EXPECT_EQ("i686--windows-elf", Triple::normalize("i686-win32-elf"));
EXPECT_EQ("i686-pc-windows-macho", Triple::normalize("i686-pc-win32-macho"));
EXPECT_EQ("i686--windows-macho", Triple::normalize("i686-win32-macho"));
EXPECT_EQ("x86_64-pc-windows-elf", Triple::normalize("x86_64-pc-win32-elf"));
EXPECT_EQ("x86_64--windows-elf", Triple::normalize("x86_64-win32-elf"));
EXPECT_EQ("x86_64-pc-windows-macho", Triple::normalize("x86_64-pc-win32-macho"));
EXPECT_EQ("x86_64--windows-macho", Triple::normalize("x86_64-win32-macho"));
Support: generalise object type handling for Windows This generalises the object file type parsing to all Windows environments. This is used by cygwin as well as MSVC environments for MCJIT. This also makes the triple more similar to Chandler's suggestion of a separate field for the object file format. llvm-svn: 205219
2014-04-01 00:34:41 +08:00
EXPECT_EQ("i686-pc-windows-cygnus",
Triple::normalize("i686-pc-windows-cygnus"));
EXPECT_EQ("i686-pc-windows-gnu", Triple::normalize("i686-pc-windows-gnu"));
Canonicalise Windows target triple spellings Construct a uniform Windows target triple nomenclature which is congruent to the Linux counterpart. The old triples are normalised to the new canonical form. This cleans up the long-standing issue of odd naming for various Windows environments. There are four different environments on Windows: MSVC: The MS ABI, MSVCRT environment as defined by Microsoft GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries Itanium: The MSVCRT environment + libc++ built with Itanium ABI Cygnus: The Cygwin environment which uses custom libraries for everything The following spellings are now written as: i686-pc-win32 => i686-pc-windows-msvc i686-pc-mingw32 => i686-pc-windows-gnu i686-pc-cygwin => i686-pc-windows-cygnus This should be sufficiently flexible to allow us to target other windows environments in the future as necessary. llvm-svn: 204977
2014-03-28 06:50:05 +08:00
EXPECT_EQ("i686-pc-windows-itanium", Triple::normalize("i686-pc-windows-itanium"));
Support: correct Windows normalisation If the environment is unknown and no object file is provided, then assume an "MSVC" environment, otherwise, set the environment to the object file format. In the case that we have a known environment but a non-native file format for Windows (COFF) which is used for MCJIT, then append the custom file format to the triple as an additional component. This fixes the MCJIT tests on Windows. llvm-svn: 205130
2014-03-30 15:19:31 +08:00
EXPECT_EQ("i686-pc-windows-msvc", Triple::normalize("i686-pc-windows-msvc"));
Support: generalise object type handling for Windows This generalises the object file type parsing to all Windows environments. This is used by cygwin as well as MSVC environments for MCJIT. This also makes the triple more similar to Chandler's suggestion of a separate field for the object file format. llvm-svn: 205219
2014-04-01 00:34:41 +08:00
EXPECT_EQ("i686-pc-windows-elf", Triple::normalize("i686-pc-windows-elf-elf"));
Canonicalise Windows target triple spellings Construct a uniform Windows target triple nomenclature which is congruent to the Linux counterpart. The old triples are normalised to the new canonical form. This cleans up the long-standing issue of odd naming for various Windows environments. There are four different environments on Windows: MSVC: The MS ABI, MSVCRT environment as defined by Microsoft GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries Itanium: The MSVCRT environment + libc++ built with Itanium ABI Cygnus: The Cygwin environment which uses custom libraries for everything The following spellings are now written as: i686-pc-win32 => i686-pc-windows-msvc i686-pc-mingw32 => i686-pc-windows-gnu i686-pc-cygwin => i686-pc-windows-cygnus This should be sufficiently flexible to allow us to target other windows environments in the future as necessary. llvm-svn: 204977
2014-03-28 06:50:05 +08:00
}
Move the API and implementation of clang::driver::getARMCPUForMArch() to llvm::Triple::getARMCPUForArch(). Suggested by Eric Christopher. llvm-svn: 212846
2014-07-12 05:44:54 +08:00
TEST(TripleTest, getARMCPUForArch) {
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
// Standard ARM Architectures.
Add unit test for r217454 llvm-svn: 217786
2014-09-16 00:57:12 +08:00
{
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
llvm::Triple Triple("armv4-unknown-eabi");
EXPECT_STREQ("strongarm", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv4t-unknown-eabi");
EXPECT_STREQ("arm7tdmi", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv5-unknown-eabi");
EXPECT_STREQ("arm10tdmi", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv5t-unknown-eabi");
EXPECT_STREQ("arm10tdmi", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv5e-unknown-eabi");
EXPECT_STREQ("arm1022e", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv5tej-unknown-eabi");
EXPECT_STREQ("arm926ej-s", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv6-unknown-eabi");
EXPECT_STREQ("arm1136jf-s", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv6j-unknown-eabi");
EXPECT_STREQ("arm1136j-s", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv6k-unknown-eabi");
Add unit test for r217454 llvm-svn: 217786
2014-09-16 00:57:12 +08:00
EXPECT_STREQ("arm1176jzf-s", Triple.getARMCPUForArch());
}
Move the API and implementation of clang::driver::getARMCPUForMArch() to llvm::Triple::getARMCPUForArch(). Suggested by Eric Christopher. llvm-svn: 212846
2014-07-12 05:44:54 +08:00
{
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
llvm::Triple Triple("armv6zk-unknown-eabi");
EXPECT_STREQ("arm1176jzf-s", Triple.getARMCPUForArch());
Move the API and implementation of clang::driver::getARMCPUForMArch() to llvm::Triple::getARMCPUForArch(). Suggested by Eric Christopher. llvm-svn: 212846
2014-07-12 05:44:54 +08:00
}
{
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
llvm::Triple Triple("armv6t2-unknown-eabi");
EXPECT_STREQ("arm1156t2-s", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv6m-unknown-eabi");
EXPECT_STREQ("cortex-m0", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7-unknown-eabi");
Move the API and implementation of clang::driver::getARMCPUForMArch() to llvm::Triple::getARMCPUForArch(). Suggested by Eric Christopher. llvm-svn: 212846
2014-07-12 05:44:54 +08:00
EXPECT_STREQ("cortex-a8", Triple.getARMCPUForArch());
}
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
{
llvm::Triple Triple("armv7a-unknown-eabi");
EXPECT_STREQ("cortex-a8", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7m-unknown-eabi");
EXPECT_STREQ("cortex-m3", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7r-unknown-eabi");
EXPECT_STREQ("cortex-r4", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7r-unknown-eabi");
EXPECT_STREQ("cortex-r4", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7r-unknown-eabi");
EXPECT_STREQ("cortex-r4", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7r-unknown-eabi");
EXPECT_STREQ("cortex-r4", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv8a-unknown-eabi");
EXPECT_STREQ("cortex-a53", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv8.1a-unknown-eabi");
EXPECT_STREQ("generic", Triple.getARMCPUForArch());
}
// Non-synonym names, using -march style, not default arch.
{
llvm::Triple Triple("arm");
EXPECT_STREQ("cortex-a8", Triple.getARMCPUForArch("armv7-a"));
}
{
llvm::Triple Triple("arm");
EXPECT_STREQ("cortex-m3", Triple.getARMCPUForArch("armv7-m"));
}
{
llvm::Triple Triple("arm");
EXPECT_STREQ("cortex-a53", Triple.getARMCPUForArch("armv8"));
}
{
llvm::Triple Triple("arm");
EXPECT_STREQ("cortex-a53", Triple.getARMCPUForArch("armv8-a"));
}
// Platform specific defaults.
Default to armv7 cpu for NaCl when march=arm Summary: When the arch is given as "arm" clang uses the default target CPU from LLVM to determine what the real arch should be (i.e. "arm" becomes "armv4t" because LLVM's getARMCPUForArch falls back to "arm7tdmi"). Default to "cortex-a8" so that we end up with "armv7" in clang. the nacl-direct.c test in clang also covers this case. Differential Revision: http://reviews.llvm.org/D8589 llvm-svn: 233321
2015-03-27 05:58:46 +08:00
{
llvm::Triple Triple("arm--nacl");
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
EXPECT_STREQ("cortex-a8", Triple.getARMCPUForArch());
Default to armv7 cpu for NaCl when march=arm Summary: When the arch is given as "arm" clang uses the default target CPU from LLVM to determine what the real arch should be (i.e. "arm" becomes "armv4t" because LLVM's getARMCPUForArch falls back to "arm7tdmi"). Default to "cortex-a8" so that we end up with "armv7" in clang. the nacl-direct.c test in clang also covers this case. Differential Revision: http://reviews.llvm.org/D8589 llvm-svn: 233321
2015-03-27 05:58:46 +08:00
}
[ARM] Reject invalid -march values Restructure Triple::getARMCPUForArch so that invalid values will return nullptr, while retaining the behaviour that an argument specifying no particular architecture version will give a default CPU. This will be used by clang to give an error on invalid -march values. Also restructure the extraction of the architecture version from the MArch string a little to hopefully make what it's doing clearer. Differential Revision: http://reviews.llvm.org/D9599 llvm-svn: 236845
2015-05-08 20:52:02 +08:00
{
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
llvm::Triple Triple("armv6-unknown-freebsd");
EXPECT_STREQ("arm1176jzf-s", Triple.getARMCPUForArch());
[ARM] Reject invalid -march values Restructure Triple::getARMCPUForArch so that invalid values will return nullptr, while retaining the behaviour that an argument specifying no particular architecture version will give a default CPU. This will be used by clang to give an error on invalid -march values. Also restructure the extraction of the architecture version from the MArch string a little to hopefully make what it's doing clearer. Differential Revision: http://reviews.llvm.org/D9599 llvm-svn: 236845
2015-05-08 20:52:02 +08:00
}
{
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
llvm::Triple Triple("arm--win32");
EXPECT_STREQ("cortex-a9", Triple.getARMCPUForArch());
[ARM] Reject invalid -march values Restructure Triple::getARMCPUForArch so that invalid values will return nullptr, while retaining the behaviour that an argument specifying no particular architecture version will give a default CPU. This will be used by clang to give an error on invalid -march values. Also restructure the extraction of the architecture version from the MArch string a little to hopefully make what it's doing clearer. Differential Revision: http://reviews.llvm.org/D9599 llvm-svn: 236845
2015-05-08 20:52:02 +08:00
}
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
// Some alternative architectures
[ARM] Reject invalid -march values Restructure Triple::getARMCPUForArch so that invalid values will return nullptr, while retaining the behaviour that an argument specifying no particular architecture version will give a default CPU. This will be used by clang to give an error on invalid -march values. Also restructure the extraction of the architecture version from the MArch string a little to hopefully make what it's doing clearer. Differential Revision: http://reviews.llvm.org/D9599 llvm-svn: 236845
2015-05-08 20:52:02 +08:00
{
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
llvm::Triple Triple("xscale-unknown-eabi");
EXPECT_STREQ("xscale", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("iwmmxt-unknown-eabi");
EXPECT_STREQ("iwmmxt", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7s-apple-ios7");
EXPECT_STREQ("swift", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7em-apple-ios7");
EXPECT_STREQ("cortex-m4", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7l-linux-gnueabihf");
EXPECT_STREQ("cortex-a8", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv6sm-apple-ios7");
EXPECT_STREQ("cortex-m0", Triple.getARMCPUForArch());
[ARM] Reject invalid -march values Restructure Triple::getARMCPUForArch so that invalid values will return nullptr, while retaining the behaviour that an argument specifying no particular architecture version will give a default CPU. This will be used by clang to give an error on invalid -march values. Also restructure the extraction of the architecture version from the MArch string a little to hopefully make what it's doing clearer. Differential Revision: http://reviews.llvm.org/D9599 llvm-svn: 236845
2015-05-08 20:52:02 +08:00
}
// armeb is permitted, but armebeb is not
{
llvm::Triple Triple("armeb-none-eabi");
EXPECT_STREQ("arm7tdmi", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armebeb-none-eabi");
EXPECT_EQ(nullptr, Triple.getARMCPUForArch());
}
Get Triple::getARMCPUForArch() to use TargetParser First ARMTargetParser FIXME, conservatively changing the way we parse CPUs in the back-end. Still not perfect, with a lot of special cases, but moving towards a more generic solution. Moving all logic to the target parser made some unwritten assumptions about architectures in Clang to break. I've added a lot of architectures required by Clang, and default to CPUs that Clang believes it should (and I agree). I've also added a lot of unit tests, with the correct CPU for each architecture, and Clang seems to be working correctly, too. It also became clear that using "unsigned ID" as the argument for the get methods makes it hard to know what ID, so I also changed the argument names to match the enum type names. llvm-svn: 237797
2015-05-20 23:05:07 +08:00
{
llvm::Triple Triple("armebv6eb-none-eabi");
EXPECT_EQ(nullptr, Triple.getARMCPUForArch());
}
// armebv6 and armv6eb are permitted, but armebv6eb is not
{
llvm::Triple Triple("armebv6-non-eabi");
EXPECT_STREQ("arm1136jf-s", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv6eb-none-eabi");
EXPECT_STREQ("arm1136jf-s", Triple.getARMCPUForArch());
}
[ARM] Reject invalid -march values Restructure Triple::getARMCPUForArch so that invalid values will return nullptr, while retaining the behaviour that an argument specifying no particular architecture version will give a default CPU. This will be used by clang to give an error on invalid -march values. Also restructure the extraction of the architecture version from the MArch string a little to hopefully make what it's doing clearer. Differential Revision: http://reviews.llvm.org/D9599 llvm-svn: 236845
2015-05-08 20:52:02 +08:00
// xscaleeb is permitted, but armebxscale is not
{
llvm::Triple Triple("xscaleeb-none-eabi");
EXPECT_STREQ("xscale", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armebxscale-none-eabi");
EXPECT_EQ(nullptr, Triple.getARMCPUForArch());
}
Move the API and implementation of clang::driver::getARMCPUForMArch() to llvm::Triple::getARMCPUForArch(). Suggested by Eric Christopher. llvm-svn: 212846
2014-07-12 05:44:54 +08:00
}
The canonical CPU variant for ARM according to config.guess uses a suffix it seems: # ./config.guess earmv7hfeb-unknown-netbsd7.99.4 Extend the triple parsing to support this. Avoid running the ARM parser multiple times because StringSwitch is not lazy. Reviewers: Renato Golin, Tim Northover Differential Revision: http://reviews.llvm.org/D7166 llvm-svn: 227085
2015-01-26 19:41:48 +08:00
TEST(TripleTest, NormalizeARM) {
EXPECT_EQ("armv6--netbsd-eabi", Triple::normalize("armv6-netbsd-eabi"));
EXPECT_EQ("armv7--netbsd-eabi", Triple::normalize("armv7-netbsd-eabi"));
EXPECT_EQ("armv6eb--netbsd-eabi", Triple::normalize("armv6eb-netbsd-eabi"));
EXPECT_EQ("armv7eb--netbsd-eabi", Triple::normalize("armv7eb-netbsd-eabi"));
EXPECT_EQ("armv6--netbsd-eabihf", Triple::normalize("armv6-netbsd-eabihf"));
EXPECT_EQ("armv7--netbsd-eabihf", Triple::normalize("armv7-netbsd-eabihf"));
EXPECT_EQ("armv6eb--netbsd-eabihf", Triple::normalize("armv6eb-netbsd-eabihf"));
EXPECT_EQ("armv7eb--netbsd-eabihf", Triple::normalize("armv7eb-netbsd-eabihf"));
Triple T;
T = Triple("armv6--netbsd-eabi");
EXPECT_EQ(Triple::arm, T.getArch());
T = Triple("armv6eb--netbsd-eabi");
EXPECT_EQ(Triple::armeb, T.getArch());
}
Move unit test into anonymous namespace as per convention. llvm-svn: 236332
2015-05-02 02:51:06 +08:00
Make Triple::parseARMArch use ARMTargetParser Simplifying Triple::parseARMArch, leaving all the parsing to ARMTargetParser. This commit also adds AArch64 detection to ARMTargetParser canonicalization, and a two RedHat arch names (v{6,7}hl, meaning hard-float / little-endian). Adding enough unit tests to cover the basics. Clang checks fine. llvm-svn: 237902
2015-05-21 21:52:20 +08:00
TEST(TripleTest, ParseARMArch) {
// ARM
{
Triple T = Triple("arm");
EXPECT_EQ(Triple::arm, T.getArch());
}
{
Triple T = Triple("armv6t2");
EXPECT_EQ(Triple::arm, T.getArch());
}
{
Triple T = Triple("armv8");
EXPECT_EQ(Triple::arm, T.getArch());
}
{
Triple T = Triple("armeb");
EXPECT_EQ(Triple::armeb, T.getArch());
}
{
Triple T = Triple("armv5eb");
EXPECT_EQ(Triple::armeb, T.getArch());
}
// THUMB
{
Triple T = Triple("thumb");
EXPECT_EQ(Triple::thumb, T.getArch());
}
{
Triple T = Triple("thumbv7a");
EXPECT_EQ(Triple::thumb, T.getArch());
}
{
Triple T = Triple("thumbeb");
EXPECT_EQ(Triple::thumbeb, T.getArch());
}
{
Triple T = Triple("thumbv4teb");
EXPECT_EQ(Triple::thumbeb, T.getArch());
}
{
Triple T = Triple("thumbv2");
EXPECT_EQ(Triple::UnknownArch, T.getArch());
}
// AARCH64
{
Triple T = Triple("arm64");
EXPECT_EQ(Triple::aarch64, T.getArch());
}
{
Triple T = Triple("aarch64");
EXPECT_EQ(Triple::aarch64, T.getArch());
}
{
Triple T = Triple("aarch64_be");
EXPECT_EQ(Triple::aarch64_be, T.getArch());
}
{
Triple T = Triple("aarch64be");
EXPECT_EQ(Triple::UnknownArch, T.getArch());
}
{
Triple T = Triple("arm64be");
EXPECT_EQ(Triple::UnknownArch, T.getArch());
}
}
Move unit test into anonymous namespace as per convention. llvm-svn: 236332
2015-05-02 02:51:06 +08:00
} // end anonymous namespace