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

1452 lines
52 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 ---------------------------===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
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
//
//===----------------------------------------------------------------------===//
#include "llvm/ADT/Triple.h"
Re-sort #include lines for unittests. This uses a slightly modified clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
2017-06-06 19:06:56 +08:00
#include "gtest/gtest.h"
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
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
[X86] Make elfiamcu an OS, not an environment. GNU tools require elfiamcu to take up the entire OS field, so, e.g. i?86-*-linux-elfiamcu is not considered a legal triple. Make us compatible. Differential Revision: http://reviews.llvm.org/D14081 llvm-svn: 251390
2015-10-27 15:23:59 +08:00
T = Triple("i386-pc-elfiamcu");
[X86] Add support for elfiamcu triple This adds support for the i?86-*-elfiamcu triple, which indicates the IAMCU psABI is used. Differential Revision: http://reviews.llvm.org/D13977 llvm-svn: 251222
2015-10-25 16:07:37 +08:00
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
[X86] Make elfiamcu an OS, not an environment. GNU tools require elfiamcu to take up the entire OS field, so, e.g. i?86-*-linux-elfiamcu is not considered a legal triple. Make us compatible. Differential Revision: http://reviews.llvm.org/D14081 llvm-svn: 251390
2015-10-27 15:23:59 +08:00
EXPECT_EQ(Triple::ELFIAMCU, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Define "contiki" OS specifier. Patch by Michael LeMay Differential revision: http://reviews.llvm.org/D24897 llvm-svn: 284240
2016-10-14 22:41:46 +08:00
T = Triple("i386-pc-contiki-unknown");
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::Contiki, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
[X86] Add support for elfiamcu triple This adds support for the i?86-*-elfiamcu triple, which indicates the IAMCU psABI is used. Differential Revision: http://reviews.llvm.org/D13977 llvm-svn: 251222
2015-10-25 16:07:37 +08:00
Add Hurd target to LLVMSupport (1/2) Add the required target triples to LLVMSupport to support Hurd in LLVM (formally `pc-hurd-gnu`). Patch by sthibaul (Samuel Thibault) Differential Revision: https://reviews.llvm.org/D54378 llvm-svn: 347832
2018-11-29 11:23:01 +08:00
T = Triple("i386-pc-hurd-gnu");
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::Hurd, T.getOS());
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
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 a Musl environment to the triple. It will be used in clang. Patch by Lei Zhang. llvm-svn: 272660
2016-06-14 20:45:33 +08:00
T = Triple("x86_64-pc-linux-musl");
EXPECT_EQ(Triple::x86_64, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::Musl, T.getEnvironment());
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());
[ADT] Recognize ppc as valid architecture in target triple. Until this patch, only `powerpc` and `ppc32` were recognized as valid PowerPC 32-bit architectures in a target triple. This was incompatible with the triple `ppc-apple-darwin` as returned for libObject. I found out about this when working on a test case using a binary generated on an old PowerBook G4. We had the choice of either fix this in the Mach-O object parser or in the Triple implementation. I chose the latter because it feels like the most canonical place. Differential revision: https://reviews.llvm.org/D43760 llvm-svn: 326182
2018-02-27 18:09:58 +08:00
T = Triple("ppc-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("ppc32-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());
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("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());
[ADT] Recognize ppc as valid architecture in target triple. Until this patch, only `powerpc` and `ppc32` were recognized as valid PowerPC 32-bit architectures in a target triple. This was incompatible with the triple `ppc-apple-darwin` as returned for libObject. I found out about this when working on a test case using a binary generated on an old PowerBook G4. We had the choice of either fix this in the Mach-O object parser or in the Triple implementation. I chose the latter because it feels like the most canonical place. Differential revision: https://reviews.llvm.org/D43760 llvm-svn: 326182
2018-02-27 18:09:58 +08:00
T = Triple("ppc64-bgq-linux");
EXPECT_EQ(Triple::ppc64, T.getArch());
EXPECT_EQ(Triple::BGQ, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
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());
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273726
2016-06-25 05:14:33 +08:00
T = Triple("arm-none-linux-musleabi");
EXPECT_EQ(Triple::arm, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::MuslEABI, 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 Ananas platform Ananas is a home-brew operating system, mainly for amd64 machines. After using GCC for quite some time, it has switched to clang and never looked back - yet, having to manually patch things is annoying, so it'd be much nicer if this was in the official tree. More information: https://github.com/zhmu/ananas/ https://rink.nu/projects/ananas.html Submitted by: Rink Springer Differential Revision: https://reviews.llvm.org/D32937 llvm-svn: 306237
2017-06-25 16:19:37 +08:00
T = Triple("x86_64-unknown-ananas");
EXPECT_EQ(Triple::x86_64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Ananas, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
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());
[Triple] Add triple for Fuchsia Fuchsia is a new operating system. Differential Revision: https://reviews.llvm.org/D25116 llvm-svn: 283419
2016-10-06 13:17:26 +08:00
T = Triple("x86_64-unknown-fuchsia");
EXPECT_EQ(Triple::x86_64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Fuchsia, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
This patch adds support to LLVM for writing HermitCore (https://hermitcore.org) ELF binaries. HermitCore is a POSIX-compatible kernel for running a single application in an isolated environment to get maximum performance and predictable runtime behavior. It can either be used bare-metal on hardware or a VM (Unikernel) or side by side to an existing Linux system (Multikernel). Due to the latter feature, HermitCore binaries are marked with ELFOSABI_STANDALONE to let the Linux ELF loader distinguish them from regular Unix/Linux binaries and load them using the HermitCore "proxy" tool. Patch by Colin Finck! llvm-svn: 340675
2018-08-25 09:08:18 +08:00
T = Triple("x86_64-unknown-hermit");
EXPECT_EQ(Triple::x86_64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::HermitCore, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Drop the OS from the WebAssembly target triple for now. This unbreaks TripleTest.Normalization. We'll have to come up with a new plan for the OS component of the target triple for WebAssembly. llvm-svn: 241041
2015-06-30 11:52:25 +08:00
T = Triple("wasm32-unknown-unknown");
[WebAssembly] Initial WebAssembly backend This WebAssembly backend is just a skeleton at this time and is not yet functional. llvm-svn: 241022
2015-06-30 07:51:55 +08:00
EXPECT_EQ(Triple::wasm32, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
Drop the OS from the WebAssembly target triple for now. This unbreaks TripleTest.Normalization. We'll have to come up with a new plan for the OS component of the target triple for WebAssembly. llvm-svn: 241041
2015-06-30 11:52:25 +08:00
EXPECT_EQ(Triple::UnknownOS, T.getOS());
[WebAssembly] Initial WebAssembly backend This WebAssembly backend is just a skeleton at this time and is not yet functional. llvm-svn: 241022
2015-06-30 07:51:55 +08:00
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
[WebAssembly] COWS has been renamed to WASI. llvm-svn: 351297
2019-01-16 13:23:52 +08:00
T = Triple("wasm32-unknown-wasi-musl");
[WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses it This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. [Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/ Differential Revision: https://reviews.llvm.org/D56553 llvm-svn: 351163
2019-01-15 14:58:13 +08:00
EXPECT_EQ(Triple::wasm32, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
[WebAssembly] COWS has been renamed to WASI. llvm-svn: 351297
2019-01-16 13:23:52 +08:00
EXPECT_EQ(Triple::WASI, T.getOS());
[WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses it This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. [Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/ Differential Revision: https://reviews.llvm.org/D56553 llvm-svn: 351163
2019-01-15 14:58:13 +08:00
EXPECT_EQ(Triple::Musl, T.getEnvironment());
Drop the OS from the WebAssembly target triple for now. This unbreaks TripleTest.Normalization. We'll have to come up with a new plan for the OS component of the target triple for WebAssembly. llvm-svn: 241041
2015-06-30 11:52:25 +08:00
T = Triple("wasm64-unknown-unknown");
[WebAssembly] Initial WebAssembly backend This WebAssembly backend is just a skeleton at this time and is not yet functional. llvm-svn: 241022
2015-06-30 07:51:55 +08:00
EXPECT_EQ(Triple::wasm64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
Drop the OS from the WebAssembly target triple for now. This unbreaks TripleTest.Normalization. We'll have to come up with a new plan for the OS component of the target triple for WebAssembly. llvm-svn: 241041
2015-06-30 11:52:25 +08:00
EXPECT_EQ(Triple::UnknownOS, T.getOS());
[WebAssembly] Initial WebAssembly backend This WebAssembly backend is just a skeleton at this time and is not yet functional. llvm-svn: 241022
2015-06-30 07:51:55 +08:00
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
[WebAssembly] COWS has been renamed to WASI. llvm-svn: 351297
2019-01-16 13:23:52 +08:00
T = Triple("wasm64-unknown-wasi-musl");
[WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses it This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. [Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/ Differential Revision: https://reviews.llvm.org/D56553 llvm-svn: 351163
2019-01-15 14:58:13 +08:00
EXPECT_EQ(Triple::wasm64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
[WebAssembly] COWS has been renamed to WASI. llvm-svn: 351297
2019-01-16 13:23:52 +08:00
EXPECT_EQ(Triple::WASI, T.getOS());
[WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses it This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. [Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/ Differential Revision: https://reviews.llvm.org/D56553 llvm-svn: 351163
2019-01-15 14:58:13 +08:00
EXPECT_EQ(Triple::Musl, T.getEnvironment());
Initial migration of AVR backend This patch adds the underlying infrastructure for an AVR backend to be included into LLVM. It is the first of a series of patches aimed at moving the out-of-tree AVR backend into the tree. It consists of adding a new`Triple` target 'avr'. llvm-svn: 250492
2015-10-16 11:10:30 +08:00
T = Triple("avr-unknown-unknown");
EXPECT_EQ(Triple::avr, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("avr");
EXPECT_EQ(Triple::avr, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
[lanai] Add Lanai triple. Add triple for the Lanai backend. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend". Differential Revision: http://reviews.llvm.org/D17003 llvm-svn: 260545
2016-02-12 01:16:20 +08:00
T = Triple("lanai-unknown-unknown");
EXPECT_EQ(Triple::lanai, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("lanai");
EXPECT_EQ(Triple::lanai, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Add AMDGPU related triple vendors/OSes As support expands to more runtimes, we'll need to distinguish between more than just HSA and unknown. This also lets us stop using unknown everywhere. llvm-svn: 260790
2016-02-13 09:56:21 +08:00
T = Triple("amdgcn-mesa-mesa3d");
EXPECT_EQ(Triple::amdgcn, T.getArch());
EXPECT_EQ(Triple::Mesa, T.getVendor());
EXPECT_EQ(Triple::Mesa3D, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("amdgcn-amd-amdhsa");
EXPECT_EQ(Triple::amdgcn, T.getArch());
EXPECT_EQ(Triple::AMD, T.getVendor());
EXPECT_EQ(Triple::AMDHSA, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
[lanai] Add Lanai triple. Add triple for the Lanai backend. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend". Differential Revision: http://reviews.llvm.org/D17003 llvm-svn: 260545
2016-02-12 01:16:20 +08:00
[Triple] Add AMDPAL operating system type Summary: This operating system type represents the AMDGPU PAL runtime, and will be required by the AMDGPU backend in order to generate correct code for this runtime. Currently it generates the same code as not specifying an OS at all. That will change in future commits. Patch from Tim Corringham. Subscribers: arsenm, nhaehnle Differential Revision: https://reviews.llvm.org/D37380 llvm-svn: 314500
2017-09-29 17:48:12 +08:00
T = Triple("amdgcn-amd-amdpal");
EXPECT_EQ(Triple::amdgcn, T.getArch());
EXPECT_EQ(Triple::AMD, T.getVendor());
EXPECT_EQ(Triple::AMDPAL, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
[RISCV] Recognise riscv32 and riscv64 in triple parsing code This is the first in a series of 10 initial patches that incrementally add an MC layer for RISC-V to LLVM. See <http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html> for more discussion. Differential Revision: https://reviews.llvm.org/D23557 llvm-svn: 285707
2016-11-02 00:47:54 +08:00
T = Triple("riscv32-unknown-unknown");
EXPECT_EQ(Triple::riscv32, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::UnknownOS, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("riscv64-unknown-linux");
EXPECT_EQ(Triple::riscv64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("riscv64-unknown-freebsd");
EXPECT_EQ(Triple::riscv64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::FreeBSD, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
Add SUSE vendor Summary: SUSE's ARM triples end with -gnueabi even though they are hard-float. This requires special handling of SUSE ARM triples. Hence we need a way to differentiate the SUSE as vendor. This CL adds that. Reviewers: chandlerc, compnerd, echristo, rengolin Reviewed By: rengolin Subscribers: aemerson, rengolin, llvm-commits Differential Revision: https://reviews.llvm.org/D32426 llvm-svn: 301174
2017-04-24 19:18:29 +08:00
T = Triple("armv7hl-suse-linux-gnueabi");
EXPECT_EQ(Triple::arm, T.getArch());
EXPECT_EQ(Triple::SUSE, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUEABI, T.getEnvironment());
[Triple] Define OS Check for Haiku This adds the OS check for the Haiku operating system, as it was missing in the Triple class. Tests for x86_64-unknown-haiku and i586-pc-haiku were also added. These patches only affect Haiku and are completely harmless for other platforms. Patch by Calvin Hill <calvin@hakobaito.co.uk> llvm-svn: 311153
2017-08-18 18:35:42 +08:00
T = Triple("i586-pc-haiku");
EXPECT_EQ(Triple::x86, T.getArch());
EXPECT_EQ(Triple::PC, T.getVendor());
EXPECT_EQ(Triple::Haiku, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
T = Triple("x86_64-unknown-haiku");
EXPECT_EQ(Triple::x86_64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Haiku, T.getOS());
EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
[mips] Add unitests to check parsing MIPS triples. NFC llvm-svn: 313160
2017-09-14 01:36:16 +08:00
T = Triple("mips-mti-linux-gnu");
EXPECT_EQ(Triple::mips, T.getArch());
EXPECT_EQ(Triple::MipsTechnologies, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
T = Triple("mipsel-img-linux-gnu");
EXPECT_EQ(Triple::mipsel, T.getArch());
EXPECT_EQ(Triple::ImaginationTechnologies, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
T = Triple("mips64-mti-linux-gnu");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::MipsTechnologies, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
T = Triple("mips64el-img-linux-gnu");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::ImaginationTechnologies, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
[mips] Recognise the triple used by Debian for MIPS n32 ABI Triples like mips64-linux-gnuabin32 are documented in this article: https://wiki.debian.org/Multiarch/Tuples llvm-svn: 313231
2017-09-14 14:50:05 +08:00
T = Triple("mips64el-img-linux-gnuabin32");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::ImaginationTechnologies, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
[mips] Add unitests to check parsing MIPS triples. NFC llvm-svn: 313160
2017-09-14 01:36:16 +08:00
T = Triple("mips64el-unknown-linux-gnuabi64");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mips64el");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mips64-unknown-linux-gnuabi64");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mips64");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
T = Triple("mipsisa64r6el-unknown-linux-gnuabi64");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mips64r6el");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsisa64r6el");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsisa64r6-unknown-linux-gnuabi64");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mips64r6");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsisa64r6");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABI64, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mips64el-unknown-linux-gnuabin32");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mipsn32el");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mips64-unknown-linux-gnuabin32");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mipsn32");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
T = Triple("mipsisa64r6el-unknown-linux-gnuabin32");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsn32r6el");
EXPECT_EQ(Triple::mips64el, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsisa64r6-unknown-linux-gnuabin32");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsn32r6");
EXPECT_EQ(Triple::mips64, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNUABIN32, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mipsel-unknown-linux-gnu");
EXPECT_EQ(Triple::mipsel, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mipsel");
EXPECT_EQ(Triple::mipsel, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mips-unknown-linux-gnu");
EXPECT_EQ(Triple::mips, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::Linux, T.getOS());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
EXPECT_EQ(Triple::GNU, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
[mips] Fix MIPS N32 ABI triples support Add support mips64(el)-linux-gnuabin32 triples, and set them to N32. Debian architecture name mipsn32/mipsn32el are also added. Set UseIntegratedAssembler for N32 if we can detect it. Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51408 llvm-svn: 342416
2018-09-18 05:21:57 +08:00
T = Triple("mips");
EXPECT_EQ(Triple::mips, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
[mips] Add support MIPS r6 Debian triples Debian uses different triples for MIPS r6 and paths. Here we use SubArch to determine whether it is r6, if we found `r6' in CPU section of triple. These new triples include: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D50857 llvm-svn: 343185
2018-09-27 16:51:18 +08:00
EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
T = Triple("mipsisa32r6el-unknown-linux-gnu");
EXPECT_EQ(Triple::mipsel, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsr6el");
EXPECT_EQ(Triple::mipsel, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsisa32r6el");
EXPECT_EQ(Triple::mipsel, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsisa32r6-unknown-linux-gnu");
EXPECT_EQ(Triple::mips, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsr6");
EXPECT_EQ(Triple::mips, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
T = Triple("mipsisa32r6");
EXPECT_EQ(Triple::mips, T.getArch());
EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
EXPECT_EQ(Triple::GNU, T.getEnvironment());
EXPECT_EQ(Triple::MipsSubArch_r6, T.getSubArch());
[OpenEmbedded] Add OpenEmbedded vendor Summary: The lib paths are not correctly picked up for OpenEmbedded sysroots (like arm-oe-linux-gnueabi). I fix this in a follow-up clang patch. But in order to add the correct libs I need to detect if the vendor is oe. For this reason, it is first necessary to teach llvm to detect oe vendor, which is what this patch does. Reviewers: chandlerc, compnerd, rengolin, javed.absar Reviewed By: compnerd Subscribers: kristof.beyls, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48861 llvm-svn: 336401
2018-07-06 07:41:17 +08:00
T = Triple("arm-oe-linux-gnueabi");
EXPECT_EQ(Triple::arm, T.getArch());
EXPECT_EQ(Triple::OpenEmbedded, T.getVendor());
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::GNUEABI, T.getEnvironment());
[mips] Add unitests to check parsing MIPS triples. NFC llvm-svn: 313160
2017-09-14 01:36:16 +08:00
[OpenEmbedded] Add a unittest for aarch64-oe-linux Summary: Added a unittest for aarch64-oe-linux which was missed in D48861. Reviewers: compnerd, rengolin, javed.absar Reviewed By: compnerd Subscribers: kristof.beyls, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D49314 llvm-svn: 337479
2018-07-20 02:10:03 +08:00
T = Triple("aarch64-oe-linux");
EXPECT_EQ(Triple::aarch64, T.getArch());
EXPECT_EQ(Triple::OpenEmbedded, T.getVendor());
EXPECT_EQ(Triple::Linux, 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) {
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
std::string Str = A;
Str += '-';
Str += B;
Str += '-';
Str += C;
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
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) {
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
std::string Str = A;
Str += '-';
Str += B;
Str += '-';
Str += C;
Str += '-';
Str += D;
return Str;
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
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
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("unknown", Triple::normalize(""));
EXPECT_EQ("unknown-unknown", Triple::normalize("-"));
EXPECT_EQ("unknown-unknown-unknown", Triple::normalize("--"));
EXPECT_EQ("unknown-unknown-unknown-unknown", Triple::normalize("---"));
EXPECT_EQ("unknown-unknown-unknown-unknown-unknown",
Triple::normalize("----"));
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", 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"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("unknown-pc-b-c", Triple::normalize("pc-b-c"));
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-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"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("unknown-unknown-linux-b-c", Triple::normalize("linux-b-c"));
EXPECT_EQ("a-unknown-linux-c", Triple::normalize("a-linux-c"));
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("i386-pc-a", Triple::normalize("a-pc-i386"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("i386-pc-unknown", Triple::normalize("-pc-i386"));
EXPECT_EQ("unknown-pc-linux-c", Triple::normalize("linux-pc-c"));
EXPECT_EQ("unknown-pc-linux", Triple::normalize("linux-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("i386", Triple::normalize("i386"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("unknown-pc", Triple::normalize("pc"));
EXPECT_EQ("unknown-unknown-linux", Triple::normalize("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
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("x86_64-unknown-linux-gnu", Triple::normalize("x86_64-gnu-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
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.
[ADT] Make the triple test 1000x faster through more focused test cases. The current approach isn't a long-term viable pattern. Given the set of architectures A, vendors V, operating systems O, and environments E, it does |A| * |V| * |O| * |E| * 4! tests. As LLVM grows, this test keeps getting slower, despite my working very hard to make it get some "optimizations" even in -O0 builds in order to lower the constant factors. Fundamentally, we're doing an unreasonable amount of work.i Looking at the specific thing being tested -- the goal seems very clearly to be testing the *permutations*, not the *combinations*. The combinations are driving up the complexity much more than anything else. Instead, test every possible value for a given triple entry in every permutation of *some* triple. This really seems to cover the core goal of the test. Every single possible triple component is tested in every position. But because we keep the rest of the triple constant, it does so in a dramatically more scalable amount of time. With this model we do (|A| + |V| + |O| + |E|) * 4! tests. For me on a debug build, this goes from running for 19 seconds to 19 milliseconds, or a 1000x improvement. This makes a world of difference for the critical path of 'ninja check-llvm' and other extremely common workflows. Thanks to Renato, Dean, and David for the helpful review comments and helping me refine the explanation of the change. Differential Revision: https://reviews.llvm.org/D23156 llvm-svn: 277912
2016-08-06 14:00:50 +08:00
//
// We don't check every possible combination. For the set of architectures A,
// vendors V, operating systems O, and environments E, that would require |A|
// * |V| * |O| * |E| * 4! tests. Instead we check every option for any given
// slot and make sure it gets normalized to the correct position from every
// permutation. This should cover the core logic while being a tractable
// number of tests at (|A| + |V| + |O| + |E|) * 4!.
auto FirstArchType = Triple::ArchType(Triple::UnknownArch + 1);
auto FirstVendorType = Triple::VendorType(Triple::UnknownVendor + 1);
auto FirstOSType = Triple::OSType(Triple::UnknownOS + 1);
auto FirstEnvType = Triple::EnvironmentType(Triple::UnknownEnvironment + 1);
StringRef InitialC[] = {Triple::getArchTypeName(FirstArchType),
Triple::getVendorTypeName(FirstVendorType),
Triple::getOSTypeName(FirstOSType),
Triple::getEnvironmentTypeName(FirstEnvType)};
for (int Arch = FirstArchType; Arch <= Triple::LastArchType; ++Arch) {
StringRef C[] = {InitialC[0], InitialC[1], InitialC[2], InitialC[3]};
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));
[ADT] Make the triple test 1000x faster through more focused test cases. The current approach isn't a long-term viable pattern. Given the set of architectures A, vendors V, operating systems O, and environments E, it does |A| * |V| * |O| * |E| * 4! tests. As LLVM grows, this test keeps getting slower, despite my working very hard to make it get some "optimizations" even in -O0 builds in order to lower the constant factors. Fundamentally, we're doing an unreasonable amount of work.i Looking at the specific thing being tested -- the goal seems very clearly to be testing the *permutations*, not the *combinations*. The combinations are driving up the complexity much more than anything else. Instead, test every possible value for a given triple entry in every permutation of *some* triple. This really seems to cover the core goal of the test. Every single possible triple component is tested in every position. But because we keep the rest of the triple constant, it does so in a dramatically more scalable amount of time. With this model we do (|A| + |V| + |O| + |E|) * 4! tests. For me on a debug build, this goes from running for 19 seconds to 19 milliseconds, or a 1000x improvement. This makes a world of difference for the critical path of 'ninja check-llvm' and other extremely common workflows. Thanks to Renato, Dean, and David for the helpful review comments and helping me refine the explanation of the change. Differential Revision: https://reviews.llvm.org/D23156 llvm-svn: 277912
2016-08-06 14:00:50 +08:00
std::string E = Join(C[0], C[1], C[2]);
int I[] = {0, 1, 2};
do {
EXPECT_EQ(E, Triple::normalize(Join(C[I[0]], C[I[1]], C[I[2]])));
} while (std::next_permutation(std::begin(I), std::end(I)));
std::string F = Join(C[0], C[1], C[2], C[3]);
int J[] = {0, 1, 2, 3};
do {
EXPECT_EQ(F, Triple::normalize(Join(C[J[0]], C[J[1]], C[J[2]], C[J[3]])));
} while (std::next_permutation(std::begin(J), std::end(J)));
}
for (int Vendor = FirstVendorType; Vendor <= Triple::LastVendorType;
++Vendor) {
StringRef C[] = {InitialC[0], InitialC[1], InitialC[2], InitialC[3]};
C[1] = Triple::getVendorTypeName(Triple::VendorType(Vendor));
std::string E = Join(C[0], C[1], C[2]);
int I[] = {0, 1, 2};
do {
EXPECT_EQ(E, Triple::normalize(Join(C[I[0]], C[I[1]], C[I[2]])));
} while (std::next_permutation(std::begin(I), std::end(I)));
std::string F = Join(C[0], C[1], C[2], C[3]);
int J[] = {0, 1, 2, 3};
do {
EXPECT_EQ(F, Triple::normalize(Join(C[J[0]], C[J[1]], C[J[2]], C[J[3]])));
} while (std::next_permutation(std::begin(J), std::end(J)));
}
for (int OS = FirstOSType; OS <= Triple::LastOSType; ++OS) {
if (OS == Triple::Win32)
continue;
StringRef C[] = {InitialC[0], InitialC[1], InitialC[2], InitialC[3]};
C[2] = Triple::getOSTypeName(Triple::OSType(OS));
std::string E = Join(C[0], C[1], C[2]);
int I[] = {0, 1, 2};
do {
EXPECT_EQ(E, Triple::normalize(Join(C[I[0]], C[I[1]], C[I[2]])));
} while (std::next_permutation(std::begin(I), std::end(I)));
std::string F = Join(C[0], C[1], C[2], C[3]);
int J[] = {0, 1, 2, 3};
do {
EXPECT_EQ(F, Triple::normalize(Join(C[J[0]], C[J[1]], C[J[2]], C[J[3]])));
} while (std::next_permutation(std::begin(J), std::end(J)));
}
for (int Env = FirstEnvType; Env <= Triple::LastEnvironmentType; ++Env) {
StringRef C[] = {InitialC[0], InitialC[1], InitialC[2], InitialC[3]};
C[3] = Triple::getEnvironmentTypeName(Triple::EnvironmentType(Env));
std::string F = Join(C[0], C[1], C[2], C[3]);
int J[] = {0, 1, 2, 3};
do {
EXPECT_EQ(F, Triple::normalize(Join(C[J[0]], C[J[1]], C[J[2]], C[J[3]])));
} while (std::next_permutation(std::begin(J), std::end(J)));
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.
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("i386-unknown-windows-gnu",
Triple::normalize("i386-mingw32")); // i386-pc-mingw32
EXPECT_EQ("x86_64-unknown-linux-gnu",
Triple::normalize("x86_64-linux-gnu")); // x86_64-pc-linux-gnu
EXPECT_EQ("i486-unknown-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-unknown-linux",
Triple::normalize("i686-linux")); // i686-pc-linux-gnu
EXPECT_EQ("arm-none-unknown-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());
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());
[WebAssembly] Initial WebAssembly backend This WebAssembly backend is just a skeleton at this time and is not yet functional. llvm-svn: 241022
2015-06-30 07:51:55 +08:00
T.setArch(Triple::wasm32);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::wasm64);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_TRUE(T.isArch64Bit());
Initial migration of AVR backend This patch adds the underlying infrastructure for an AVR backend to be included into LLVM. It is the first of a series of patches aimed at moving the out-of-tree AVR backend into the tree. It consists of adding a new`Triple` target 'avr'. llvm-svn: 250492
2015-10-16 11:10:30 +08:00
T.setArch(Triple::avr);
EXPECT_TRUE(T.isArch16Bit());
EXPECT_FALSE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
[lanai] Add Lanai triple. Add triple for the Lanai backend. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend". Differential Revision: http://reviews.llvm.org/D17003 llvm-svn: 260545
2016-02-12 01:16:20 +08:00
T.setArch(Triple::lanai);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
[RISCV] Recognise riscv32 and riscv64 in triple parsing code This is the first in a series of 10 initial patches that incrementally add an MC layer for RISC-V to LLVM. See <http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html> for more discussion. Differential Revision: https://reviews.llvm.org/D23557 llvm-svn: 285707
2016-11-02 00:47:54 +08:00
T.setArch(Triple::riscv32);
EXPECT_FALSE(T.isArch16Bit());
EXPECT_TRUE(T.isArch32Bit());
EXPECT_FALSE(T.isArch64Bit());
T.setArch(Triple::riscv64);
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());
[WebAssembly] Initial WebAssembly backend This WebAssembly backend is just a skeleton at this time and is not yet functional. llvm-svn: 241022
2015-06-30 07:51:55 +08:00
T.setArch(Triple::wasm32);
EXPECT_EQ(Triple::wasm32, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::wasm64, T.get64BitArchVariant().getArch());
T.setArch(Triple::wasm64);
EXPECT_EQ(Triple::wasm32, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::wasm64, T.get64BitArchVariant().getArch());
[RISCV] Recognise riscv32 and riscv64 in triple parsing code This is the first in a series of 10 initial patches that incrementally add an MC layer for RISC-V to LLVM. See <http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html> for more discussion. Differential Revision: https://reviews.llvm.org/D23557 llvm-svn: 285707
2016-11-02 00:47:54 +08:00
T.setArch(Triple::riscv32);
EXPECT_EQ(Triple::riscv32, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::riscv64, T.get64BitArchVariant().getArch());
T.setArch(Triple::riscv64);
EXPECT_EQ(Triple::riscv32, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::riscv64, T.get64BitArchVariant().getArch());
TripleTest.BitWidthArchVariants: add missing arch types (thumb, arm, le, ...) llvm-svn: 294096
2017-02-05 02:20:20 +08:00
T.setArch(Triple::thumbeb);
EXPECT_EQ(Triple::thumbeb, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::aarch64_be, T.get64BitArchVariant().getArch());
T.setArch(Triple::thumb);
EXPECT_EQ(Triple::thumb, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::aarch64, T.get64BitArchVariant().getArch());
T.setArch(Triple::aarch64);
EXPECT_EQ(Triple::arm, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::aarch64, T.get64BitArchVariant().getArch());
T.setArch(Triple::aarch64_be);
EXPECT_EQ(Triple::armeb, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::aarch64_be, T.get64BitArchVariant().getArch());
T.setArch(Triple::renderscript32);
EXPECT_EQ(Triple::renderscript32, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::renderscript64, T.get64BitArchVariant().getArch());
T.setArch(Triple::renderscript64);
EXPECT_EQ(Triple::renderscript32, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::renderscript64, T.get64BitArchVariant().getArch());
T.setArch(Triple::le32);
EXPECT_EQ(Triple::le32, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::le64, T.get64BitArchVariant().getArch());
T.setArch(Triple::le64);
EXPECT_EQ(Triple::le32, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::le64, T.get64BitArchVariant().getArch());
T.setArch(Triple::armeb);
EXPECT_EQ(Triple::armeb, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::aarch64_be, T.get64BitArchVariant().getArch());
T.setArch(Triple::arm);
EXPECT_EQ(Triple::arm, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::aarch64, T.get64BitArchVariant().getArch());
T.setArch(Triple::systemz);
EXPECT_EQ(Triple::UnknownArch, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::systemz, T.get64BitArchVariant().getArch());
T.setArch(Triple::xcore);
EXPECT_EQ(Triple::xcore, T.get32BitArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, 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
}
[Triple] Add a helper to switch between big/little endian variants This will be used from clang's driver. llvm-svn: 241527
2015-07-07 07:58:14 +08:00
TEST(TripleTest, EndianArchVariants) {
Triple T;
EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::UnknownArch);
EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::aarch64_be);
EXPECT_EQ(Triple::aarch64_be, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::aarch64, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::aarch64);
EXPECT_EQ(Triple::aarch64_be, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::aarch64, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::armeb);
EXPECT_EQ(Triple::armeb, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::arm);
EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::arm, T.getLittleEndianArchVariant().getArch());
[Triple] Reimplement isLittleEndian(). Now it works for arm too. Differential Revision: http://reviews.llvm.org/D21846 llvm-svn: 274154
2016-06-30 04:01:39 +08:00
T = Triple("arm");
EXPECT_TRUE(T.isLittleEndian());
T = Triple("thumb");
EXPECT_TRUE(T.isLittleEndian());
T = Triple("armeb");
EXPECT_FALSE(T.isLittleEndian());
T = Triple("thumbeb");
EXPECT_FALSE(T.isLittleEndian());
[Triple] Add a helper to switch between big/little endian variants This will be used from clang's driver. llvm-svn: 241527
2015-07-07 07:58:14 +08:00
T.setArch(Triple::bpfeb);
EXPECT_EQ(Triple::bpfeb, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::bpfel, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::bpfel);
EXPECT_EQ(Triple::bpfeb, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::bpfel, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::mips64);
EXPECT_EQ(Triple::mips64, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::mips64el, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::mips64el);
EXPECT_EQ(Triple::mips64, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::mips64el, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::mips);
EXPECT_EQ(Triple::mips, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::mipsel, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::mipsel);
EXPECT_EQ(Triple::mips, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::mipsel, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::ppc);
EXPECT_EQ(Triple::ppc, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::ppc64);
EXPECT_EQ(Triple::ppc64, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::ppc64le, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::ppc64le);
EXPECT_EQ(Triple::ppc64, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::ppc64le, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::sparc);
EXPECT_EQ(Triple::sparc, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::sparcel, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::sparcel);
EXPECT_EQ(Triple::sparc, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::sparcel, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::thumb);
EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::thumb, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::thumbeb);
EXPECT_EQ(Triple::thumbeb, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, T.getLittleEndianArchVariant().getArch());
[lanai] Add Lanai triple. Add triple for the Lanai backend. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend". Differential Revision: http://reviews.llvm.org/D17003 llvm-svn: 260545
2016-02-12 01:16:20 +08:00
T.setArch(Triple::lanai);
EXPECT_EQ(Triple::lanai, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::UnknownArch, T.getLittleEndianArchVariant().getArch());
TripleTest.EndianArchVariants: add missing arch types (tce, le) llvm-svn: 294095
2017-02-05 01:04:50 +08:00
T.setArch(Triple::tcele);
EXPECT_EQ(Triple::tce, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::tcele, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::tce);
EXPECT_EQ(Triple::tce, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::tcele, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::le32);
EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::le32, T.getLittleEndianArchVariant().getArch());
T.setArch(Triple::le64);
EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
EXPECT_EQ(Triple::le64, T.getLittleEndianArchVariant().getArch());
[Triple] Add a helper to switch between big/little endian variants This will be used from clang's driver. llvm-svn: 241527
2015-07-07 07:58:14 +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);
Add a new Simulator entry for the target triple environment. Apple's iOS, tvOS and watchOS simulator platforms have never been clearly distinguished in the target triples. Even though they are intended to behave similarly to the corresponding device platforms, they have separate SDKs and are really separate platforms from the compiler's perspective. Clang now defines a macro when building for one of these simulator platforms (r297866) but that relies on the very indirect mechanism of checking to see which option was used to specify the minimum deployment target. That is not so great. Swift would also like to distinguish these simulator platforms in a similar way, but unlike Clang, Swift does not use a separate option to specify the minimum deployment target -- it uses a -target option to specify the target triple directly, including the OS version number. Using a different target triple for the simulator platforms is a much more direct and obvious way to specify this. Putting the "simulator" in the environment component of the triple means the OS values can stay the same and existing code the looks at the OS field will not be affected. https://reviews.llvm.org/D39143 rdar://problem/34729432 llvm-svn: 316380
2017-10-24 05:51:50 +08:00
EXPECT_FALSE(T.isSimulatorEnvironment());
T = Triple("x86_64-apple-ios10.3-simulator");
EXPECT_TRUE(T.isiOS());
T.getiOSVersion(Major, Minor, Micro);
EXPECT_EQ((unsigned)10, Major);
EXPECT_EQ((unsigned)3, Minor);
EXPECT_EQ((unsigned)0, Micro);
EXPECT_TRUE(T.isSimulatorEnvironment());
Add unittests for Triple::getMacOSXVersion and Triple::getiOSVersion. llvm-svn: 156507
2012-05-10 03:31:41 +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
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
[WebAssembly] Update ADT/TripleTest.cpp now that default file format has changed Differential Revision: https://reviews.llvm.org/D43212 llvm-svn: 324966
2018-02-13 07:47:38 +08:00
EXPECT_EQ(Triple::Wasm, Triple("wasm32-unknown-unknown").getObjectFormat());
EXPECT_EQ(Triple::Wasm, Triple("wasm64-unknown-unknown").getObjectFormat());
[WebAssembly] COWS has been renamed to WASI. llvm-svn: 351297
2019-01-16 13:23:52 +08:00
EXPECT_EQ(Triple::Wasm, Triple("wasm32-unknown-wasi-musl").getObjectFormat());
EXPECT_EQ(Triple::Wasm, Triple("wasm64-unknown-wasi-musl").getObjectFormat());
[WebAssembly] Update ADT/TripleTest.cpp now that default file format has changed Differential Revision: https://reviews.llvm.org/D43212 llvm-svn: 324966
2018-02-13 07:47:38 +08:00
[WebAssembly] Restore "*-wasm" tests. Even though "...-wasm" is now the default for wasm, it's still desirable to test this form. llvm-svn: 325273
2018-02-16 02:05:16 +08:00
EXPECT_EQ(Triple::Wasm,
Triple("wasm32-unknown-unknown-wasm").getObjectFormat());
EXPECT_EQ(Triple::Wasm,
Triple("wasm64-unknown-unknown-wasm").getObjectFormat());
[WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses it This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. [Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/ Differential Revision: https://reviews.llvm.org/D56553 llvm-svn: 351163
2019-01-15 14:58:13 +08:00
EXPECT_EQ(Triple::Wasm,
[WebAssembly] COWS has been renamed to WASI. llvm-svn: 351297
2019-01-16 13:23:52 +08:00
Triple("wasm32-unknown-wasi-musl-wasm").getObjectFormat());
[WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses it This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. [Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/ Differential Revision: https://reviews.llvm.org/D56553 llvm-svn: 351163
2019-01-15 14:58:13 +08:00
EXPECT_EQ(Triple::Wasm,
[WebAssembly] COWS has been renamed to WASI. llvm-svn: 351297
2019-01-16 13:23:52 +08:00
Triple("wasm64-unknown-wasi-musl-wasm").getObjectFormat());
[WebAssembly] Restore "*-wasm" tests. Even though "...-wasm" is now the default for wasm, it's still desirable to test this form. llvm-svn: 325273
2018-02-16 02:05:16 +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());
TripleTest.FileFormat: check non-default value Triple::objectFormat defaults to an Elf format. Changing objectFormat to Elf doesn't make any difference. llvm-svn: 294104
2017-02-05 06:49:22 +08:00
T.setObjectFormat(Triple::MachO);
EXPECT_EQ(Triple::MachO, T.getObjectFormat());
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
}
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"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("i686-unknown-windows-msvc", Triple::normalize("i686-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
EXPECT_EQ("i686-pc-windows-gnu", Triple::normalize("i686-pc-mingw32"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("i686-unknown-windows-gnu", Triple::normalize("i686-mingw32"));
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-gnu", Triple::normalize("i686-pc-mingw32-w64"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("i686-unknown-windows-gnu", Triple::normalize("i686-mingw32-w64"));
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-cygnus", Triple::normalize("i686-pc-cygwin"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("i686-unknown-windows-cygnus", Triple::normalize("i686-cygwin"));
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("x86_64-pc-windows-msvc", Triple::normalize("x86_64-pc-win32"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("x86_64-unknown-windows-msvc", Triple::normalize("x86_64-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
EXPECT_EQ("x86_64-pc-windows-gnu", Triple::normalize("x86_64-pc-mingw32"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("x86_64-unknown-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-unknown-windows-gnu",
Triple::normalize("x86_64-mingw32-w64"));
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-elf", Triple::normalize("i686-pc-win32-elf"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("i686-unknown-windows-elf", Triple::normalize("i686-win32-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
EXPECT_EQ("i686-pc-windows-macho", Triple::normalize("i686-pc-win32-macho"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("i686-unknown-windows-macho",
Triple::normalize("i686-win32-macho"));
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("x86_64-pc-windows-elf", Triple::normalize("x86_64-pc-win32-elf"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("x86_64-unknown-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-unknown-windows-macho",
Triple::normalize("x86_64-win32-macho"));
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
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"));
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +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
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +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
// 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");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("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
}
Set default CPU for OpenBSD/arm to Cortex-A8 llvm-svn: 296493
2017-03-01 01:28:35 +08:00
{
llvm::Triple Triple("arm--openbsd");
EXPECT_EQ("cortex-a8", 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("armv6-unknown-freebsd");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("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
}
ARMTargetParser: Make BSD Thumb/BE armv6 work Simple change to make arch like "thumbv6" and "armbev6" to return the correct CPU for FreeBSD and NetBSD. llvm-svn: 238353
2015-05-28 03:49:53 +08:00
{
llvm::Triple Triple("thumbv6-unknown-freebsd");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("arm1176jzf-s", Triple.getARMCPUForArch());
ARMTargetParser: Make BSD Thumb/BE armv6 work Simple change to make arch like "thumbv6" and "armbev6" to return the correct CPU for FreeBSD and NetBSD. llvm-svn: 238353
2015-05-28 03:49:53 +08:00
}
{
llvm::Triple Triple("armebv6-unknown-freebsd");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("arm1176jzf-s", Triple.getARMCPUForArch());
ARMTargetParser: Make BSD Thumb/BE armv6 work Simple change to make arch like "thumbv6" and "armbev6" to return the correct CPU for FreeBSD and NetBSD. llvm-svn: 238353
2015-05-28 03:49:53 +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("arm--win32");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("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
ARMv7k: use Cortex-A7 by default even for tvOS Also actually test the default CPU from those triples. llvm-svn: 260621
2016-02-12 07:49:08 +08:00
{
llvm::Triple Triple("armv7k-apple-ios9");
EXPECT_EQ("cortex-a7", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7k-apple-watchos3");
EXPECT_EQ("cortex-a7", Triple.getARMCPUForArch());
}
{
llvm::Triple Triple("armv7k-apple-tvos9");
EXPECT_EQ("cortex-a7", 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");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("arm7tdmi", 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
}
{
llvm::Triple Triple("armebeb-none-eabi");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("", 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("armebv6eb-none-eabi");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("", 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
}
[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");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("xscale", 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
}
{
llvm::Triple Triple("armebxscale-none-eabi");
Teach the target parsing framework to directly compute the length of all of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
2015-08-30 15:51:04 +08:00
EXPECT_EQ("", 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
}
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) {
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
EXPECT_EQ("armv6-unknown-netbsd-eabi",
Triple::normalize("armv6-netbsd-eabi"));
EXPECT_EQ("armv7-unknown-netbsd-eabi",
Triple::normalize("armv7-netbsd-eabi"));
EXPECT_EQ("armv6eb-unknown-netbsd-eabi",
Triple::normalize("armv6eb-netbsd-eabi"));
EXPECT_EQ("armv7eb-unknown-netbsd-eabi",
Triple::normalize("armv7eb-netbsd-eabi"));
EXPECT_EQ("armv6-unknown-netbsd-eabihf",
Triple::normalize("armv6-netbsd-eabihf"));
EXPECT_EQ("armv7-unknown-netbsd-eabihf",
Triple::normalize("armv7-netbsd-eabihf"));
EXPECT_EQ("armv6eb-unknown-netbsd-eabihf",
Triple::normalize("armv6eb-netbsd-eabihf"));
EXPECT_EQ("armv7eb-unknown-netbsd-eabihf",
Triple::normalize("armv7eb-netbsd-eabihf"));
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
ADT: handle special case of ARM environment for SUSE SUSE treats "gnueabi" as "gnueabihf" so make sure that we normalise the environment. llvm-svn: 304670
2017-06-04 06:31:06 +08:00
EXPECT_EQ("armv7-suse-linux-gnueabihf",
Revert r305642 llvm-svn: 305643
2017-06-18 18:15:57 +08:00
Triple::normalize("armv7-suse-linux-gnueabi"));
ADT: handle special case of ARM environment for SUSE SUSE treats "gnueabi" as "gnueabihf" so make sure that we normalise the environment. llvm-svn: 304670
2017-06-04 06:31:06 +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
Triple T;
T = Triple("armv6--netbsd-eabi");
EXPECT_EQ(Triple::arm, T.getArch());
T = Triple("armv6eb--netbsd-eabi");
EXPECT_EQ(Triple::armeb, T.getArch());
ADT: handle special case of ARM environment for SUSE SUSE treats "gnueabi" as "gnueabihf" so make sure that we normalise the environment. llvm-svn: 304670
2017-06-04 06:31:06 +08:00
T = Triple("armv7-suse-linux-gnueabihf");
EXPECT_EQ(Triple::GNUEABIHF, T.getEnvironment());
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
}
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("armeb");
EXPECT_EQ(Triple::armeb, T.getArch());
}
// THUMB
{
Triple T = Triple("thumb");
EXPECT_EQ(Triple::thumb, T.getArch());
}
{
Triple T = Triple("thumbeb");
EXPECT_EQ(Triple::thumbeb, 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());
}
}
Move unit test into anonymous namespace as per convention. llvm-svn: 236332
2015-05-02 02:51:06 +08:00
} // end anonymous namespace