RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 08:23:21 +01:00
Code Issues Projects Releases Wiki Activity
04bf5d54a6
llvm-mirror/unittests/ADT/TripleTest.cpp

269 lines
10 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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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 05:31:47 +02: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-01 23:53:23 +02: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-09 23:48:57 +02: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 10:25:48 +02: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-01 23:53:23 +02: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-09 23:48:57 +02: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-21 19:25:47 +01: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-01 23:53:23 +02: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-09 23:48:57 +02: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 10:25:48 +02: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-01 23:53:23 +02: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 11:08:38 +01: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-21 19:25:47 +01: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 11:08:38 +01: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-21 19:25:47 +01:00
EXPECT_EQ(Triple::EABI, 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-01 23:53:23 +02: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-09 23:48:57 +02: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 13:31:39 +02:00
}
Improve Triple to recognize the OS in i386-mingw32. llvm-svn: 79359
2009-08-18 21:26:55 +02: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 13:31:39 +02: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-18 21:26:55 +02: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 13:31:39 +02: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-18 21:26:55 +02: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 13:31:39 +02: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-21 19:25:47 +01: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 13:31:39 +02: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 10:25:48 +02: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 13:31:39 +02: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 10:25:48 +02: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 13:31:39 +02: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-21 19:25:47 +01: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 13:31:39 +02:00
// Check that normalizing a permutated set of valid components returns a
// triple with the unpermuted components.
StringRef C[4];
for (int Arch = 1+Triple::UnknownArch; Arch < Triple::InvalidArch; ++Arch) {
C[0] = Triple::getArchTypeName(Triple::ArchType(Arch));
for (int Vendor = 1+Triple::UnknownVendor; Vendor <= Triple::PC;
++Vendor) {
C[1] = Triple::getVendorTypeName(Triple::VendorType(Vendor));
for (int OS = 1+Triple::UnknownOS; OS <= Triple::Minix; ++OS) {
C[2] = Triple::getOSTypeName(Triple::OSType(OS));
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 11:08:38 +01:00
for (int Env = 1+Triple::UnknownEnvironment; Env <= Triple::MachO;
++Env) {
C[3] = Triple::getEnvironmentTypeName(Triple::EnvironmentType(Env));
std::string E = Join(C[0], C[1], C[2]);
std::string F = Join(C[0], C[1], C[2], C[3]);
EXPECT_EQ(E, Triple::normalize(Join(C[0], C[1], C[2])));
EXPECT_EQ(F, Triple::normalize(Join(C[0], C[1], C[2], C[3])));
// If a value has multiple interpretations, then the permutation
// test will inevitably fail. Currently this is only the case for
// "psp" which parses as both an architecture and an O/S.
if (OS == Triple::Psp)
continue;
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])));
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 13:31:39 +02:00
}
}
}
EXPECT_EQ("a-b-psp", Triple::normalize("a-b-psp"));
EXPECT_EQ("psp-b-c", Triple::normalize("psp-b-c"));
// Various real-world funky triples. The value returned by GCC's config.sub
// is given in the comment.
EXPECT_EQ("i386--mingw32", Triple::normalize("i386-mingw32")); // i386-pc-mingw32
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 11:08:38 +01: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-01 23:53:23 +02: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-09 23:48:57 +02: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 10:25:48 +02: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-01 23:53:23 +02: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-09 23:48:57 +02: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-01 23:53:23 +02: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-09 23:48:57 +02: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-01 23:53:23 +02: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-09 23:48:57 +02: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-01 23:53:23 +02: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-09 23:48:57 +02: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-01 23:53:23 +02: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-09 23:48:57 +02: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-01 23:53:23 +02: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-09 23:48:57 +02: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-21 19:25:47 +01: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-01 23:53:23 +02:00
}
}
Reference in New Issue Copy Permalink