maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Support/Triple.cpp

1152 lines
36 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 - Target triple helper class --------------------------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "llvm/ADT/Triple.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "llvm/ADT/STLExtras.h"
r83391 was completely broken since Twines keep references to their inputs, and some of the inputs were temporaries. Here's a real fix for the miscompilation. Thanks to sabre for pointing out the problem. llvm-svn: 83417
2009-10-07 05:45:26 +08:00
#include "llvm/ADT/SmallString.h"
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
#include "llvm/ADT/StringSwitch.h"
More dead code removal (using -Wunreachable-code) llvm-svn: 148578
2012-01-21 05:51:11 +08:00
#include "llvm/Support/ErrorHandling.h"
Fix build on Linux. llvm-svn: 68269
2009-04-02 09:11:37 +08:00
#include <cstring>
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;
const char *Triple::getArchTypeName(ArchType Kind) {
switch (Kind) {
case UnknownArch: return "unknown";
Trailing whitespace and 80 column fixups. llvm-svn: 122026
2010-12-17 10:10:59 +08:00
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case aarch64: return "aarch64";
case aarch64_be: return "aarch64_be";
case arm: return "arm";
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case armeb: return "armeb";
BPF backend Summary: V8->V9: - cleanup tests V7->V8: - addressed feedback from David: - switched to range-based 'for' loops - fixed formatting of tests V6->V7: - rebased and adjusted AsmPrinter args - CamelCased .td, fixed formatting, cleaned up names, removed unused patterns - diffstat: 3 files changed, 203 insertions(+), 227 deletions(-) V5->V6: - addressed feedback from Chandler: - reinstated full verbose standard banner in all files - fixed variables that were not in CamelCase - fixed names of #ifdef in header files - removed redundant braces in if/else chains with single statements - fixed comments - removed trailing empty line - dropped debug annotations from tests - diffstat of these changes: 46 files changed, 456 insertions(+), 469 deletions(-) V4->V5: - fix setLoadExtAction() interface - clang-formated all where it made sense V3->V4: - added CODE_OWNERS entry for BPF backend V2->V3: - fix metadata in tests V1->V2: - addressed feedback from Tom and Matt - removed top level change to configure (now everything via 'experimental-backend') - reworked error reporting via DiagnosticInfo (similar to R600) - added few more tests - added cmake build - added Triple::bpf - tested on linux and darwin V1 cover letter: --------------------- recently linux gained "universal in-kernel virtual machine" which is called eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since new instruction set is based on it. This patch adds a new backend that emits extended BPF instruction set. The concept and development are covered by the following articles: http://lwn.net/Articles/599755/ http://lwn.net/Articles/575531/ http://lwn.net/Articles/603983/ http://lwn.net/Articles/606089/ http://lwn.net/Articles/612878/ One of use cases: dtrace/systemtap alternative. bpf syscall manpage: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe instruction set description and differences vs classic BPF: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt Short summary of instruction set: - 64-bit registers R0 - return value from in-kernel function, and exit value for BPF program R1 - R5 - arguments from BPF program to in-kernel function R6 - R9 - callee saved registers that in-kernel function will preserve R10 - read-only frame pointer to access stack - two-operand instructions like +, -, *, mov, load/store - implicit prologue/epilogue (invisible stack pointer) - no floating point, no simd Short history of extended BPF in kernel: interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future. It's a very small and simple backend. There is no support for global variables, arbitrary function calls, floating point, varargs, exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc. From C front-end point of view it's very restricted. It's done on purpose, since kernel rejects all programs that it cannot prove safe. It rejects programs with loops and with memory accesses via arbitrary pointers. When kernel accepts the program it is guaranteed that program will terminate and will not crash the kernel. This patch implements all 'must have' bits. There are several things on TODO list, so this is not the end of development. Most of the code is a boiler plate code, copy-pasted from other backends. Only odd things are lack or < and <= instructions, specialized load_byte intrinsics and 'compare and goto' as single instruction. Current instruction set is fixed, but more instructions can be added in the future. Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D6494 llvm-svn: 227008
2015-01-25 01:51:26 +08:00
case bpf: return "bpf";
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case hexagon: return "hexagon";
case mips: return "mips";
case mipsel: return "mipsel";
case mips64: return "mips64";
case mips64el: return "mips64el";
case msp430: return "msp430";
case ppc64: return "powerpc64";
case ppc64le: return "powerpc64le";
case ppc: return "powerpc";
case r600: return "r600";
Triple: Add amdgcn triple This will be used for AMD GPUs with the Graphics Core Next architecture, which are currently using by the r600 triple. llvm-svn: 225276
2015-01-07 02:00:00 +08:00
case amdgcn: return "amdgcn";
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case sparc: return "sparc";
case sparcv9: return "sparcv9";
case systemz: return "s390x";
case tce: return "tce";
case thumb: return "thumb";
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case thumbeb: return "thumbeb";
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case x86: return "i386";
case x86_64: return "x86_64";
case xcore: return "xcore";
case nvptx: return "nvptx";
case nvptx64: return "nvptx64";
case le32: return "le32";
Add support for le64. Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Depends on D5318. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5319 llvm-svn: 217697
2014-09-13 01:54:17 +08:00
case le64: return "le64";
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case amdil: return "amdil";
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case amdil64: return "amdil64";
case hsail: return "hsail";
case hsail64: return "hsail64";
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case spir: return "spir";
case spir64: return "spir64";
Add the CSR company and the Kalimba DSP processor to Triple. Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
2014-07-11 01:26:54 +08:00
case kalimba: return "kalimba";
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
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148578
2012-01-21 05:51:11 +08:00
llvm_unreachable("Invalid ArchType!");
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 llvm::Triple::getArchTypePrefix for getting the intrinsic prefix for an identifier architecture. llvm-svn: 79906
2009-08-24 17:53:06 +08:00
const char *Triple::getArchTypePrefix(ArchType Kind) {
switch (Kind) {
default:
[C++11] Make use of 'nullptr' in the Support library. llvm-svn: 205697
2014-04-07 12:17:22 +08:00
return nullptr;
Add llvm::Triple::getArchTypePrefix for getting the intrinsic prefix for an identifier architecture. llvm-svn: 79906
2009-08-24 17:53:06 +08:00
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case aarch64:
case aarch64_be: return "aarch64";
Add AArch64 as an experimental target. This patch adds support for AArch64 (ARM's 64-bit architecture) to LLVM in the "experimental" category. Currently, it won't be built unless requested explicitly. This initial commit should have support for: + Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions (except the late addition CRC instructions). + CodeGen features required for C++03 and C99. + Compilation for the "small" memory model: code+static data < 4GB. + Absolute and position-independent code. + GNU-style (i.e. "__thread") TLS. + Debugging information. The principal omission, currently, is performance tuning. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174054
2013-01-31 20:12:40 +08:00
Add llvm::Triple::getArchTypePrefix for getting the intrinsic prefix for an identifier architecture. llvm-svn: 79906
2009-08-24 17:53:06 +08:00
case arm:
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case armeb:
case thumb:
case thumbeb: return "arm";
Add llvm::Triple::getArchTypePrefix for getting the intrinsic prefix for an identifier architecture. llvm-svn: 79906
2009-08-24 17:53:06 +08:00
case ppc64:
[PowerPC] Support powerpc64le as a syntax-checking target. This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
2013-07-26 09:35:43 +08:00
case ppc64le:
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case ppc: return "ppc";
Add llvm::Triple::getArchTypePrefix for getting the intrinsic prefix for an identifier architecture. llvm-svn: 79906
2009-08-24 17:53:06 +08:00
Enable automatic GCC<->LLVM intrinsic translation for mips. llvm-svn: 159367
2012-06-29 03:09:53 +08:00
case mips:
case mipsel:
case mips64:
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case mips64el: return "mips";
Enable automatic GCC<->LLVM intrinsic translation for mips. llvm-svn: 159367
2012-06-29 03:09:53 +08:00
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case hexagon: return "hexagon";
Hexagon backend support llvm-svn: 146412
2011-12-13 05:14:40 +08:00
Triple: Add amdgcn triple This will be used for AMD GPUs with the Graphics Core Next architecture, which are currently using by the r600 triple. llvm-svn: 225276
2015-01-07 02:00:00 +08:00
case amdgcn:
case r600: return "amdgpu";
Add support for r600 (AMD GPUs HD2XXX - HD6XXX) target triplet. Patch by Tom Stellard! llvm-svn: 152400
2012-03-09 18:09:36 +08:00
BPF backend Summary: V8->V9: - cleanup tests V7->V8: - addressed feedback from David: - switched to range-based 'for' loops - fixed formatting of tests V6->V7: - rebased and adjusted AsmPrinter args - CamelCased .td, fixed formatting, cleaned up names, removed unused patterns - diffstat: 3 files changed, 203 insertions(+), 227 deletions(-) V5->V6: - addressed feedback from Chandler: - reinstated full verbose standard banner in all files - fixed variables that were not in CamelCase - fixed names of #ifdef in header files - removed redundant braces in if/else chains with single statements - fixed comments - removed trailing empty line - dropped debug annotations from tests - diffstat of these changes: 46 files changed, 456 insertions(+), 469 deletions(-) V4->V5: - fix setLoadExtAction() interface - clang-formated all where it made sense V3->V4: - added CODE_OWNERS entry for BPF backend V2->V3: - fix metadata in tests V1->V2: - addressed feedback from Tom and Matt - removed top level change to configure (now everything via 'experimental-backend') - reworked error reporting via DiagnosticInfo (similar to R600) - added few more tests - added cmake build - added Triple::bpf - tested on linux and darwin V1 cover letter: --------------------- recently linux gained "universal in-kernel virtual machine" which is called eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since new instruction set is based on it. This patch adds a new backend that emits extended BPF instruction set. The concept and development are covered by the following articles: http://lwn.net/Articles/599755/ http://lwn.net/Articles/575531/ http://lwn.net/Articles/603983/ http://lwn.net/Articles/606089/ http://lwn.net/Articles/612878/ One of use cases: dtrace/systemtap alternative. bpf syscall manpage: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe instruction set description and differences vs classic BPF: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt Short summary of instruction set: - 64-bit registers R0 - return value from in-kernel function, and exit value for BPF program R1 - R5 - arguments from BPF program to in-kernel function R6 - R9 - callee saved registers that in-kernel function will preserve R10 - read-only frame pointer to access stack - two-operand instructions like +, -, *, mov, load/store - implicit prologue/epilogue (invisible stack pointer) - no floating point, no simd Short history of extended BPF in kernel: interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future. It's a very small and simple backend. There is no support for global variables, arbitrary function calls, floating point, varargs, exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc. From C front-end point of view it's very restricted. It's done on purpose, since kernel rejects all programs that it cannot prove safe. It rejects programs with loops and with memory accesses via arbitrary pointers. When kernel accepts the program it is guaranteed that program will terminate and will not crash the kernel. This patch implements all 'must have' bits. There are several things on TODO list, so this is not the end of development. Most of the code is a boiler plate code, copy-pasted from other backends. Only odd things are lack or < and <= instructions, specialized load_byte intrinsics and 'compare and goto' as single instruction. Current instruction set is fixed, but more instructions can be added in the future. Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D6494 llvm-svn: 227008
2015-01-25 01:51:26 +08:00
case bpf: return "bpf";
add support for the sparcv9-*-* target triple to turn on 64-bit sparc codegen. Patch by Nathan Keynes! llvm-svn: 95293
2010-02-04 14:34:01 +08:00
case sparcv9:
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case sparc: return "sparc";
Add llvm::Triple::getArchTypePrefix for getting the intrinsic prefix for an identifier architecture. llvm-svn: 79906
2009-08-24 17:53:06 +08:00
[SystemZ] Support transactional execution on zEC12 The zEC12 provides the transactional-execution facility. This is exposed to users via a set of builtin routines on other compilers. This patch adds LLVM support to enable those builtins. In partciular, the patch: - adds the transactional-execution and processor-assist facilities - adds MC support for all instructions provided by those facilities - adds LLVM intrinsics for those instructions and hooks them up for CodeGen - adds CodeGen support to optimize CC return value checking Since this is first use of target-specific intrinsics on the platform, the patch creates the include/llvm/IR/IntrinsicsSystemZ.td file and hooks it up in Intrinsics.td. I've also changed Triple::getArchTypePrefix to return "s390" instead of "systemz", since the naming convention for GCC intrinsics uses "s390" on the platform, and it neemed more straight- forward to use the same convention for LLVM IR intrinsics. An associated clang patch makes the intrinsics (and command line switches) available at the source-language level. For reference, the transactional-execution instructions are documented in the z/Architecture Principles of Operation for the zEC12: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/download/DZ9ZR009.pdf The associated builtins are documented in the GCC manual: http://gcc.gnu.org/onlinedocs/gcc/S_002f390-System-z-Built-in-Functions.html Index: llvm-head/lib/Target/SystemZ/SystemZOperators.td =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZOperators.td +++ llvm-head/lib/Target/SystemZ/SystemZOperators.td @@ -79,6 +79,9 @@ def SDT_ZI32Intrinsic : SDTypeProf def SDT_ZPrefetch : SDTypeProfile<0, 2, [SDTCisVT<0, i32>, SDTCisPtrTy<1>]>; +def SDT_ZTBegin : SDTypeProfile<0, 2, + [SDTCisPtrTy<0>, + SDTCisVT<1, i32>]>; //===----------------------------------------------------------------------===// // Node definitions @@ -180,6 +183,15 @@ def z_prefetch : SDNode<"System [SDNPHasChain, SDNPMayLoad, SDNPMayStore, SDNPMemOperand]>; +def z_tbegin : SDNode<"SystemZISD::TBEGIN", SDT_ZTBegin, + [SDNPHasChain, SDNPOutGlue, SDNPMayStore, + SDNPSideEffect]>; +def z_tbegin_nofloat : SDNode<"SystemZISD::TBEGIN_NOFLOAT", SDT_ZTBegin, + [SDNPHasChain, SDNPOutGlue, SDNPMayStore, + SDNPSideEffect]>; +def z_tend : SDNode<"SystemZISD::TEND", SDTNone, + [SDNPHasChain, SDNPOutGlue, SDNPSideEffect]>; + //===----------------------------------------------------------------------===// // Pattern fragments //===----------------------------------------------------------------------===// Index: llvm-head/lib/Target/SystemZ/SystemZInstrFormats.td =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZInstrFormats.td +++ llvm-head/lib/Target/SystemZ/SystemZInstrFormats.td @@ -473,6 +473,17 @@ class InstSS<bits<8> op, dag outs, dag i let Inst{15-0} = BD2; } +class InstS<bits<16> op, dag outs, dag ins, string asmstr, list<dag> pattern> + : InstSystemZ<4, outs, ins, asmstr, pattern> { + field bits<32> Inst; + field bits<32> SoftFail = 0; + + bits<16> BD2; + + let Inst{31-16} = op; + let Inst{15-0} = BD2; +} + //===----------------------------------------------------------------------===// // Instruction definitions with semantics //===----------------------------------------------------------------------===// Index: llvm-head/lib/Target/SystemZ/SystemZInstrInfo.td =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZInstrInfo.td +++ llvm-head/lib/Target/SystemZ/SystemZInstrInfo.td @@ -1362,6 +1362,60 @@ let Defs = [CC] in { } //===----------------------------------------------------------------------===// +// Transactional execution +//===----------------------------------------------------------------------===// + +let Predicates = [FeatureTransactionalExecution] in { + // Transaction Begin + let hasSideEffects = 1, mayStore = 1, + usesCustomInserter = 1, Defs = [CC] in { + def TBEGIN : InstSIL<0xE560, + (outs), (ins bdaddr12only:$BD1, imm32zx16:$I2), + "tbegin\t$BD1, $I2", + [(z_tbegin bdaddr12only:$BD1, imm32zx16:$I2)]>; + def TBEGIN_nofloat : Pseudo<(outs), (ins bdaddr12only:$BD1, imm32zx16:$I2), + [(z_tbegin_nofloat bdaddr12only:$BD1, + imm32zx16:$I2)]>; + def TBEGINC : InstSIL<0xE561, + (outs), (ins bdaddr12only:$BD1, imm32zx16:$I2), + "tbeginc\t$BD1, $I2", + [(int_s390_tbeginc bdaddr12only:$BD1, + imm32zx16:$I2)]>; + } + + // Transaction End + let hasSideEffects = 1, Defs = [CC], BD2 = 0 in + def TEND : InstS<0xB2F8, (outs), (ins), "tend", [(z_tend)]>; + + // Transaction Abort + let hasSideEffects = 1, isTerminator = 1, isBarrier = 1 in + def TABORT : InstS<0xB2FC, (outs), (ins bdaddr12only:$BD2), + "tabort\t$BD2", + [(int_s390_tabort bdaddr12only:$BD2)]>; + + // Nontransactional Store + let hasSideEffects = 1 in + def NTSTG : StoreRXY<"ntstg", 0xE325, int_s390_ntstg, GR64, 8>; + + // Extract Transaction Nesting Depth + let hasSideEffects = 1 in + def ETND : InherentRRE<"etnd", 0xB2EC, GR32, (int_s390_etnd)>; +} + +//===----------------------------------------------------------------------===// +// Processor assist +//===----------------------------------------------------------------------===// + +let Predicates = [FeatureProcessorAssist] in { + let hasSideEffects = 1, R4 = 0 in + def PPA : InstRRF<0xB2E8, (outs), (ins GR64:$R1, GR64:$R2, imm32zx4:$R3), + "ppa\t$R1, $R2, $R3", []>; + def : Pat<(int_s390_ppa_txassist GR32:$src), + (PPA (INSERT_SUBREG (i64 (IMPLICIT_DEF)), GR32:$src, subreg_l32), + 0, 1)>; +} + +//===----------------------------------------------------------------------===// // Miscellaneous Instructions. //===----------------------------------------------------------------------===// Index: llvm-head/lib/Target/SystemZ/SystemZProcessors.td =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZProcessors.td +++ llvm-head/lib/Target/SystemZ/SystemZProcessors.td @@ -60,6 +60,16 @@ def FeatureMiscellaneousExtensions : Sys "Assume that the miscellaneous-extensions facility is installed" >; +def FeatureTransactionalExecution : SystemZFeature< + "transactional-execution", "TransactionalExecution", + "Assume that the transactional-execution facility is installed" +>; + +def FeatureProcessorAssist : SystemZFeature< + "processor-assist", "ProcessorAssist", + "Assume that the processor-assist facility is installed" +>; + def : Processor<"generic", NoItineraries, []>; def : Processor<"z10", NoItineraries, []>; def : Processor<"z196", NoItineraries, @@ -70,4 +80,5 @@ def : Processor<"zEC12", NoItineraries, [FeatureDistinctOps, FeatureLoadStoreOnCond, FeatureHighWord, FeatureFPExtension, FeaturePopulationCount, FeatureFastSerialization, FeatureInterlockedAccess1, - FeatureMiscellaneousExtensions]>; + FeatureMiscellaneousExtensions, + FeatureTransactionalExecution, FeatureProcessorAssist]>; Index: llvm-head/lib/Target/SystemZ/SystemZSubtarget.cpp =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZSubtarget.cpp +++ llvm-head/lib/Target/SystemZ/SystemZSubtarget.cpp @@ -40,6 +40,7 @@ SystemZSubtarget::SystemZSubtarget(const HasLoadStoreOnCond(false), HasHighWord(false), HasFPExtension(false), HasPopulationCount(false), HasFastSerialization(false), HasInterlockedAccess1(false), HasMiscellaneousExtensions(false), + HasTransactionalExecution(false), HasProcessorAssist(false), TargetTriple(TT), InstrInfo(initializeSubtargetDependencies(CPU, FS)), TLInfo(TM, *this), TSInfo(*TM.getDataLayout()), FrameLowering() {} Index: llvm-head/lib/Target/SystemZ/SystemZSubtarget.h =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZSubtarget.h +++ llvm-head/lib/Target/SystemZ/SystemZSubtarget.h @@ -42,6 +42,8 @@ protected: bool HasFastSerialization; bool HasInterlockedAccess1; bool HasMiscellaneousExtensions; + bool HasTransactionalExecution; + bool HasProcessorAssist; private: Triple TargetTriple; @@ -102,6 +104,12 @@ public: return HasMiscellaneousExtensions; } + // Return true if the target has the transactional-execution facility. + bool hasTransactionalExecution() const { return HasTransactionalExecution; } + + // Return true if the target has the processor-assist facility. + bool hasProcessorAssist() const { return HasProcessorAssist; } + // Return true if GV can be accessed using LARL for reloc model RM // and code model CM. bool isPC32DBLSymbol(const GlobalValue *GV, Reloc::Model RM, Index: llvm-head/lib/Support/Triple.cpp =================================================================== --- llvm-head.orig/lib/Support/Triple.cpp +++ llvm-head/lib/Support/Triple.cpp @@ -92,7 +92,7 @@ const char *Triple::getArchTypePrefix(Ar case sparcv9: case sparc: return "sparc"; - case systemz: return "systemz"; + case systemz: return "s390"; case x86: case x86_64: return "x86"; Index: llvm-head/include/llvm/IR/Intrinsics.td =================================================================== --- llvm-head.orig/include/llvm/IR/Intrinsics.td +++ llvm-head/include/llvm/IR/Intrinsics.td @@ -634,3 +634,4 @@ include "llvm/IR/IntrinsicsNVVM.td" include "llvm/IR/IntrinsicsMips.td" include "llvm/IR/IntrinsicsR600.td" include "llvm/IR/IntrinsicsBPF.td" +include "llvm/IR/IntrinsicsSystemZ.td" Index: llvm-head/include/llvm/IR/IntrinsicsSystemZ.td =================================================================== --- /dev/null +++ llvm-head/include/llvm/IR/IntrinsicsSystemZ.td @@ -0,0 +1,46 @@ +//===- IntrinsicsSystemZ.td - Defines SystemZ intrinsics ---*- tablegen -*-===// +// +// The LLVM Compiler Infrastructure +// +// This file is distributed under the University of Illinois Open Source +// License. See LICENSE.TXT for details. +// +//===----------------------------------------------------------------------===// +// +// This file defines all of the SystemZ-specific intrinsics. +// +//===----------------------------------------------------------------------===// + +//===----------------------------------------------------------------------===// +// +// Transactional-execution intrinsics +// +//===----------------------------------------------------------------------===// + +let TargetPrefix = "s390" in { + def int_s390_tbegin : Intrinsic<[llvm_i32_ty], [llvm_ptr_ty, llvm_i32_ty], + [IntrNoDuplicate]>; + + def int_s390_tbegin_nofloat : Intrinsic<[llvm_i32_ty], + [llvm_ptr_ty, llvm_i32_ty], + [IntrNoDuplicate]>; + + def int_s390_tbeginc : Intrinsic<[], [llvm_ptr_ty, llvm_i32_ty], + [IntrNoDuplicate]>; + + def int_s390_tabort : Intrinsic<[], [llvm_i64_ty], + [IntrNoReturn, Throws]>; + + def int_s390_tend : GCCBuiltin<"__builtin_tend">, + Intrinsic<[llvm_i32_ty], []>; + + def int_s390_etnd : GCCBuiltin<"__builtin_tx_nesting_depth">, + Intrinsic<[llvm_i32_ty], [], [IntrNoMem]>; + + def int_s390_ntstg : Intrinsic<[], [llvm_i64_ty, llvm_ptr64_ty], + [IntrReadWriteArgMem]>; + + def int_s390_ppa_txassist : GCCBuiltin<"__builtin_tx_assist">, + Intrinsic<[], [llvm_i32_ty]>; +} + Index: llvm-head/lib/Target/SystemZ/SystemZ.h =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZ.h +++ llvm-head/lib/Target/SystemZ/SystemZ.h @@ -68,6 +68,18 @@ const unsigned CCMASK_TM_MSB_0 = C const unsigned CCMASK_TM_MSB_1 = CCMASK_2 | CCMASK_3; const unsigned CCMASK_TM = CCMASK_ANY; +// Condition-code mask assignments for TRANSACTION_BEGIN. +const unsigned CCMASK_TBEGIN_STARTED = CCMASK_0; +const unsigned CCMASK_TBEGIN_INDETERMINATE = CCMASK_1; +const unsigned CCMASK_TBEGIN_TRANSIENT = CCMASK_2; +const unsigned CCMASK_TBEGIN_PERSISTENT = CCMASK_3; +const unsigned CCMASK_TBEGIN = CCMASK_ANY; + +// Condition-code mask assignments for TRANSACTION_END. +const unsigned CCMASK_TEND_TX = CCMASK_0; +const unsigned CCMASK_TEND_NOTX = CCMASK_2; +const unsigned CCMASK_TEND = CCMASK_TEND_TX | CCMASK_TEND_NOTX; + // The position of the low CC bit in an IPM result. const unsigned IPM_CC = 28; Index: llvm-head/lib/Target/SystemZ/SystemZISelLowering.h =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZISelLowering.h +++ llvm-head/lib/Target/SystemZ/SystemZISelLowering.h @@ -146,6 +146,15 @@ enum { // Perform a serialization operation. (BCR 15,0 or BCR 14,0.) SERIALIZE, + // Transaction begin. The first operand is the chain, the second + // the TDB pointer, and the third the immediate control field. + // Returns chain and glue. + TBEGIN, + TBEGIN_NOFLOAT, + + // Transaction end. Just the chain operand. Returns chain and glue. + TEND, + // Wrappers around the inner loop of an 8- or 16-bit ATOMIC_SWAP or // ATOMIC_LOAD_<op>. // @@ -318,6 +327,7 @@ private: SDValue lowerSTACKSAVE(SDValue Op, SelectionDAG &DAG) const; SDValue lowerSTACKRESTORE(SDValue Op, SelectionDAG &DAG) const; SDValue lowerPREFETCH(SDValue Op, SelectionDAG &DAG) const; + SDValue lowerINTRINSIC_W_CHAIN(SDValue Op, SelectionDAG &DAG) const; // If the last instruction before MBBI in MBB was some form of COMPARE, // try to replace it with a COMPARE AND BRANCH just before MBBI. @@ -355,6 +365,10 @@ private: MachineBasicBlock *emitStringWrapper(MachineInstr *MI, MachineBasicBlock *BB, unsigned Opcode) const; + MachineBasicBlock *emitTransactionBegin(MachineInstr *MI, + MachineBasicBlock *MBB, + unsigned Opcode, + bool NoFloat) const; }; } // end namespace llvm Index: llvm-head/lib/Target/SystemZ/SystemZISelLowering.cpp =================================================================== --- llvm-head.orig/lib/Target/SystemZ/SystemZISelLowering.cpp +++ llvm-head/lib/Target/SystemZ/SystemZISelLowering.cpp @@ -20,6 +20,7 @@ #include "llvm/CodeGen/MachineInstrBuilder.h" #include "llvm/CodeGen/MachineRegisterInfo.h" #include "llvm/CodeGen/TargetLoweringObjectFileImpl.h" +#include "llvm/IR/Intrinsics.h" #include <cctype> using namespace llvm; @@ -304,6 +305,9 @@ SystemZTargetLowering::SystemZTargetLowe // Codes for which we want to perform some z-specific combinations. setTargetDAGCombine(ISD::SIGN_EXTEND); + // Handle intrinsics. + setOperationAction(ISD::INTRINSIC_W_CHAIN, MVT::Other, Custom); + // We want to use MVC in preference to even a single load/store pair. MaxStoresPerMemcpy = 0; MaxStoresPerMemcpyOptSize = 0; @@ -1031,6 +1035,53 @@ prepareVolatileOrAtomicLoad(SDValue Chai return DAG.getNode(SystemZISD::SERIALIZE, DL, MVT::Other, Chain); } +// Return true if Op is an intrinsic node with chain that returns the CC value +// as its only (other) argument. Provide the associated SystemZISD opcode and +// the mask of valid CC values if so. +static bool isIntrinsicWithCCAndChain(SDValue Op, unsigned &Opcode, + unsigned &CCValid) { + unsigned Id = cast<ConstantSDNode>(Op.getOperand(1))->getZExtValue(); + switch (Id) { + case Intrinsic::s390_tbegin: + Opcode = SystemZISD::TBEGIN; + CCValid = SystemZ::CCMASK_TBEGIN; + return true; + + case Intrinsic::s390_tbegin_nofloat: + Opcode = SystemZISD::TBEGIN_NOFLOAT; + CCValid = SystemZ::CCMASK_TBEGIN; + return true; + + case Intrinsic::s390_tend: + Opcode = SystemZISD::TEND; + CCValid = SystemZ::CCMASK_TEND; + return true; + + default: + return false; + } +} + +// Emit an intrinsic with chain with a glued value instead of its CC result. +static SDValue emitIntrinsicWithChainAndGlue(SelectionDAG &DAG, SDValue Op, + unsigned Opcode) { + // Copy all operands except the intrinsic ID. + unsigned NumOps = Op.getNumOperands(); + SmallVector<SDValue, 6> Ops; + Ops.reserve(NumOps - 1); + Ops.push_back(Op.getOperand(0)); + for (unsigned I = 2; I < NumOps; ++I) + Ops.push_back(Op.getOperand(I)); + + assert(Op->getNumValues() == 2 && "Expected only CC result and chain"); + SDVTList RawVTs = DAG.getVTList(MVT::Other, MVT::Glue); + SDValue Intr = DAG.getNode(Opcode, SDLoc(Op), RawVTs, Ops); + SDValue OldChain = SDValue(Op.getNode(), 1); + SDValue NewChain = SDValue(Intr.getNode(), 0); + DAG.ReplaceAllUsesOfValueWith(OldChain, NewChain); + return Intr; +} + // CC is a comparison that will be implemented using an integer or // floating-point comparison. Return the condition code mask for // a branch on true. In the integer case, CCMASK_CMP_UO is set for @@ -1588,9 +1639,53 @@ static void adjustForTestUnderMask(Selec C.CCMask = NewCCMask; } +// Return a Comparison that tests the condition-code result of intrinsic +// node Call against constant integer CC using comparison code Cond. +// Opcode is the opcode of the SystemZISD operation for the intrinsic +// and CCValid is the set of possible condition-code results. +static Comparison getIntrinsicCmp(SelectionDAG &DAG, unsigned Opcode, + SDValue Call, unsigned CCValid, uint64_t CC, + ISD::CondCode Cond) { + Comparison C(Call, SDValue()); + C.Opcode = Opcode; + C.CCValid = CCValid; + if (Cond == ISD::SETEQ) + // bit 3 for CC==0, bit 0 for CC==3, always false for CC>3. + C.CCMask = CC < 4 ? 1 << (3 - CC) : 0; + else if (Cond == ISD::SETNE) + // ...and the inverse of that. + C.CCMask = CC < 4 ? ~(1 << (3 - CC)) : -1; + else if (Cond == ISD::SETLT || Cond == ISD::SETULT) + // bits above bit 3 for CC==0 (always false), bits above bit 0 for CC==3, + // always true for CC>3. + C.CCMask = CC < 4 ? -1 << (4 - CC) : -1; + else if (Cond == ISD::SETGE || Cond == ISD::SETUGE) + // ...and the inverse of that. + C.CCMask = CC < 4 ? ~(-1 << (4 - CC)) : 0; + else if (Cond == ISD::SETLE || Cond == ISD::SETULE) + // bit 3 and above for CC==0, bit 0 and above for CC==3 (always true), + // always true for CC>3. + C.CCMask = CC < 4 ? -1 << (3 - CC) : -1; + else if (Cond == ISD::SETGT || Cond == ISD::SETUGT) + // ...and the inverse of that. + C.CCMask = CC < 4 ? ~(-1 << (3 - CC)) : 0; + else + llvm_unreachable("Unexpected integer comparison type"); + C.CCMask &= CCValid; + return C; +} + // Decide how to implement a comparison of type Cond between CmpOp0 with CmpOp1. static Comparison getCmp(SelectionDAG &DAG, SDValue CmpOp0, SDValue CmpOp1, ISD::CondCode Cond) { + if (CmpOp1.getOpcode() == ISD::Constant) { + uint64_t Constant = cast<ConstantSDNode>(CmpOp1)->getZExtValue(); + unsigned Opcode, CCValid; + if (CmpOp0.getOpcode() == ISD::INTRINSIC_W_CHAIN && + CmpOp0.getResNo() == 0 && CmpOp0->hasNUsesOfValue(1, 0) && + isIntrinsicWithCCAndChain(CmpOp0, Opcode, CCValid)) + return getIntrinsicCmp(DAG, Opcode, CmpOp0, CCValid, Constant, Cond); + } Comparison C(CmpOp0, CmpOp1); C.CCMask = CCMaskForCondCode(Cond); if (C.Op0.getValueType().isFloatingPoint()) { @@ -1632,6 +1727,17 @@ static Comparison getCmp(SelectionDAG &D // Emit the comparison instruction described by C. static SDValue emitCmp(SelectionDAG &DAG, SDLoc DL, Comparison &C) { + if (!C.Op1.getNode()) { + SDValue Op; + switch (C.Op0.getOpcode()) { + case ISD::INTRINSIC_W_CHAIN: + Op = emitIntrinsicWithChainAndGlue(DAG, C.Op0, C.Opcode); + break; + default: + llvm_unreachable("Invalid comparison operands"); + } + return SDValue(Op.getNode(), Op->getNumValues() - 1); + } if (C.Opcode == SystemZISD::ICMP) return DAG.getNode(SystemZISD::ICMP, DL, MVT::Glue, C.Op0, C.Op1, DAG.getConstant(C.ICmpType, MVT::i32)); @@ -1713,7 +1819,6 @@ SDValue SystemZTargetLowering::lowerSETC } SDValue SystemZTargetLowering::lowerBR_CC(SDValue Op, SelectionDAG &DAG) const { - SDValue Chain = Op.getOperand(0); ISD::CondCode CC = cast<CondCodeSDNode>(Op.getOperand(1))->get(); SDValue CmpOp0 = Op.getOperand(2); SDValue CmpOp1 = Op.getOperand(3); @@ -1723,7 +1828,7 @@ SDValue SystemZTargetLowering::lowerBR_C Comparison C(getCmp(DAG, CmpOp0, CmpOp1, CC)); SDValue Glue = emitCmp(DAG, DL, C); return DAG.getNode(SystemZISD::BR_CCMASK, DL, Op.getValueType(), - Chain, DAG.getConstant(C.CCValid, MVT::i32), + Op.getOperand(0), DAG.getConstant(C.CCValid, MVT::i32), DAG.getConstant(C.CCMask, MVT::i32), Dest, Glue); } @@ -2561,6 +2666,30 @@ SDValue SystemZTargetLowering::lowerPREF Node->getMemoryVT(), Node->getMemOperand()); } +// Return an i32 that contains the value of CC immediately after After, +// whose final operand must be MVT::Glue. +static SDValue getCCResult(SelectionDAG &DAG, SDNode *After) { + SDValue Glue = SDValue(After, After->getNumValues() - 1); + SDValue IPM = DAG.getNode(SystemZISD::IPM, SDLoc(After), MVT::i32, Glue); + return DAG.getNode(ISD::SRL, SDLoc(After), MVT::i32, IPM, + DAG.getConstant(SystemZ::IPM_CC, MVT::i32)); +} + +SDValue +SystemZTargetLowering::lowerINTRINSIC_W_CHAIN(SDValue Op, + SelectionDAG &DAG) const { + unsigned Opcode, CCValid; + if (isIntrinsicWithCCAndChain(Op, Opcode, CCValid)) { + assert(Op->getNumValues() == 2 && "Expected only CC result and chain"); + SDValue Glued = emitIntrinsicWithChainAndGlue(DAG, Op, Opcode); + SDValue CC = getCCResult(DAG, Glued.getNode()); + DAG.ReplaceAllUsesOfValueWith(SDValue(Op.getNode(), 0), CC); + return SDValue(); + } + + return SDValue(); +} + SDValue SystemZTargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) const { switch (Op.getOpcode()) { @@ -2634,6 +2763,8 @@ SDValue SystemZTargetLowering::LowerOper return lowerSTACKRESTORE(Op, DAG); case ISD::PREFETCH: return lowerPREFETCH(Op, DAG); + case ISD::INTRINSIC_W_CHAIN: + return lowerINTRINSIC_W_CHAIN(Op, DAG); default: llvm_unreachable("Unexpected node to lower"); } @@ -2674,6 +2805,9 @@ const char *SystemZTargetLowering::getTa OPCODE(SEARCH_STRING); OPCODE(IPM); OPCODE(SERIALIZE); + OPCODE(TBEGIN); + OPCODE(TBEGIN_NOFLOAT); + OPCODE(TEND); OPCODE(ATOMIC_SWAPW); OPCODE(ATOMIC_LOADW_ADD); OPCODE(ATOMIC_LOADW_SUB); @@ -3501,6 +3635,50 @@ SystemZTargetLowering::emitStringWrapper return DoneMBB; } +// Update TBEGIN instruction with final opcode and register clobbers. +MachineBasicBlock * +SystemZTargetLowering::emitTransactionBegin(MachineInstr *MI, + MachineBasicBlock *MBB, + unsigned Opcode, + bool NoFloat) const { + MachineFunction &MF = *MBB->getParent(); + const TargetFrameLowering *TFI = Subtarget.getFrameLowering(); + const SystemZInstrInfo *TII = Subtarget.getInstrInfo(); + + // Update opcode. + MI->setDesc(TII->get(Opcode)); + + // We cannot handle a TBEGIN that clobbers the stack or frame pointer. + // Make sure to add the corresponding GRSM bits if they are missing. + uint64_t Control = MI->getOperand(2).getImm(); + static const unsigned GPRControlBit[16] = { + 0x8000, 0x8000, 0x4000, 0x4000, 0x2000, 0x2000, 0x1000, 0x1000, + 0x0800, 0x0800, 0x0400, 0x0400, 0x0200, 0x0200, 0x0100, 0x0100 + }; + Control |= GPRControlBit[15]; + if (TFI->hasFP(MF)) + Control |= GPRControlBit[11]; + MI->getOperand(2).setImm(Control); + + // Add GPR clobbers. + for (int I = 0; I < 16; I++) { + if ((Control & GPRControlBit[I]) == 0) { + unsigned Reg = SystemZMC::GR64Regs[I]; + MI->addOperand(MachineOperand::CreateReg(Reg, true, true)); + } + } + + // Add FPR clobbers. + if (!NoFloat && (Control & 4) != 0) { + for (int I = 0; I < 16; I++) { + unsigned Reg = SystemZMC::FP64Regs[I]; + MI->addOperand(MachineOperand::CreateReg(Reg, true, true)); + } + } + + return MBB; +} + MachineBasicBlock *SystemZTargetLowering:: EmitInstrWithCustomInserter(MachineInstr *MI, MachineBasicBlock *MBB) const { switch (MI->getOpcode()) { @@ -3742,6 +3920,12 @@ EmitInstrWithCustomInserter(MachineInstr return emitStringWrapper(MI, MBB, SystemZ::MVST); case SystemZ::SRSTLoop: return emitStringWrapper(MI, MBB, SystemZ::SRST); + case SystemZ::TBEGIN: + return emitTransactionBegin(MI, MBB, SystemZ::TBEGIN, false); + case SystemZ::TBEGIN_nofloat: + return emitTransactionBegin(MI, MBB, SystemZ::TBEGIN, true); + case SystemZ::TBEGINC: + return emitTransactionBegin(MI, MBB, SystemZ::TBEGINC, true); default: llvm_unreachable("Unexpected instr type to insert"); } Index: llvm-head/test/CodeGen/SystemZ/htm-intrinsics.ll =================================================================== --- /dev/null +++ llvm-head/test/CodeGen/SystemZ/htm-intrinsics.ll @@ -0,0 +1,352 @@ +; Test transactional-execution intrinsics. +; +; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=zEC12 | FileCheck %s + +declare i32 @llvm.s390.tbegin(i8 *, i32) +declare i32 @llvm.s390.tbegin.nofloat(i8 *, i32) +declare void @llvm.s390.tbeginc(i8 *, i32) +declare i32 @llvm.s390.tend() +declare void @llvm.s390.tabort(i64) +declare void @llvm.s390.ntstg(i64, i64 *) +declare i32 @llvm.s390.etnd() +declare void @llvm.s390.ppa.txassist(i32) + +; TBEGIN. +define void @test_tbegin() { +; CHECK-LABEL: test_tbegin: +; CHECK-NOT: stmg +; CHECK: std %f8, +; CHECK: std %f9, +; CHECK: std %f10, +; CHECK: std %f11, +; CHECK: std %f12, +; CHECK: std %f13, +; CHECK: std %f14, +; CHECK: std %f15, +; CHECK: tbegin 0, 65292 +; CHECK: ld %f8, +; CHECK: ld %f9, +; CHECK: ld %f10, +; CHECK: ld %f11, +; CHECK: ld %f12, +; CHECK: ld %f13, +; CHECK: ld %f14, +; CHECK: ld %f15, +; CHECK: br %r14 + call i32 @llvm.s390.tbegin(i8 *null, i32 65292) + ret void +} + +; TBEGIN (nofloat). +define void @test_tbegin_nofloat1() { +; CHECK-LABEL: test_tbegin_nofloat1: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65292 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65292) + ret void +} + +; TBEGIN (nofloat) with integer CC return value. +define i32 @test_tbegin_nofloat2() { +; CHECK-LABEL: test_tbegin_nofloat2: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65292 +; CHECK: ipm %r2 +; CHECK: srl %r2, 28 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65292) + ret i32 %res +} + +; TBEGIN (nofloat) with implicit CC check. +define void @test_tbegin_nofloat3(i32 *%ptr) { +; CHECK-LABEL: test_tbegin_nofloat3: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65292 +; CHECK: jnh {{\.L*}} +; CHECK: mvhi 0(%r2), 0 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65292) + %cmp = icmp eq i32 %res, 2 + br i1 %cmp, label %if.then, label %if.end + +if.then: ; preds = %entry + store i32 0, i32* %ptr, align 4 + br label %if.end + +if.end: ; preds = %if.then, %entry + ret void +} + +; TBEGIN (nofloat) with dual CC use. +define i32 @test_tbegin_nofloat4(i32 %pad, i32 *%ptr) { +; CHECK-LABEL: test_tbegin_nofloat4: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65292 +; CHECK: ipm %r2 +; CHECK: srl %r2, 28 +; CHECK: cijlh %r2, 2, {{\.L*}} +; CHECK: mvhi 0(%r3), 0 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65292) + %cmp = icmp eq i32 %res, 2 + br i1 %cmp, label %if.then, label %if.end + +if.then: ; preds = %entry + store i32 0, i32* %ptr, align 4 + br label %if.end + +if.end: ; preds = %if.then, %entry + ret i32 %res +} + +; TBEGIN (nofloat) with register. +define void @test_tbegin_nofloat5(i8 *%ptr) { +; CHECK-LABEL: test_tbegin_nofloat5: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0(%r2), 65292 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *%ptr, i32 65292) + ret void +} + +; TBEGIN (nofloat) with GRSM 0x0f00. +define void @test_tbegin_nofloat6() { +; CHECK-LABEL: test_tbegin_nofloat6: +; CHECK: stmg %r6, %r15, +; CHECK-NOT: std +; CHECK: tbegin 0, 3840 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 3840) + ret void +} + +; TBEGIN (nofloat) with GRSM 0xf100. +define void @test_tbegin_nofloat7() { +; CHECK-LABEL: test_tbegin_nofloat7: +; CHECK: stmg %r8, %r15, +; CHECK-NOT: std +; CHECK: tbegin 0, 61696 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 61696) + ret void +} + +; TBEGIN (nofloat) with GRSM 0xfe00 -- stack pointer added automatically. +define void @test_tbegin_nofloat8() { +; CHECK-LABEL: test_tbegin_nofloat8: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbegin 0, 65280 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 65024) + ret void +} + +; TBEGIN (nofloat) with GRSM 0xfb00 -- no frame pointer needed. +define void @test_tbegin_nofloat9() { +; CHECK-LABEL: test_tbegin_nofloat9: +; CHECK: stmg %r10, %r15, +; CHECK-NOT: std +; CHECK: tbegin 0, 64256 +; CHECK: br %r14 + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 64256) + ret void +} + +; TBEGIN (nofloat) with GRSM 0xfb00 -- frame pointer added automatically. +define void @test_tbegin_nofloat10(i64 %n) { +; CHECK-LABEL: test_tbegin_nofloat10: +; CHECK: stmg %r11, %r15, +; CHECK-NOT: std +; CHECK: tbegin 0, 65280 +; CHECK: br %r14 + %buf = alloca i8, i64 %n + call i32 @llvm.s390.tbegin.nofloat(i8 *null, i32 64256) + ret void +} + +; TBEGINC. +define void @test_tbeginc() { +; CHECK-LABEL: test_tbeginc: +; CHECK-NOT: stmg +; CHECK-NOT: std +; CHECK: tbeginc 0, 65288 +; CHECK: br %r14 + call void @llvm.s390.tbeginc(i8 *null, i32 65288) + ret void +} + +; TEND with integer CC return value. +define i32 @test_tend1() { +; CHECK-LABEL: test_tend1: +; CHECK: tend +; CHECK: ipm %r2 +; CHECK: srl %r2, 28 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tend() + ret i32 %res +} + +; TEND with implicit CC check. +define void @test_tend3(i32 *%ptr) { +; CHECK-LABEL: test_tend3: +; CHECK: tend +; CHECK: je {{\.L*}} +; CHECK: mvhi 0(%r2), 0 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tend() + %cmp = icmp eq i32 %res, 2 + br i1 %cmp, label %if.then, label %if.end + +if.then: ; preds = %entry + store i32 0, i32* %ptr, align 4 + br label %if.end + +if.end: ; preds = %if.then, %entry + ret void +} + +; TEND with dual CC use. +define i32 @test_tend2(i32 %pad, i32 *%ptr) { +; CHECK-LABEL: test_tend2: +; CHECK: tend +; CHECK: ipm %r2 +; CHECK: srl %r2, 28 +; CHECK: cijlh %r2, 2, {{\.L*}} +; CHECK: mvhi 0(%r3), 0 +; CHECK: br %r14 + %res = call i32 @llvm.s390.tend() + %cmp = icmp eq i32 %res, 2 + br i1 %cmp, label %if.then, label %if.end + +if.then: ; preds = %entry + store i32 0, i32* %ptr, align 4 + br label %if.end + +if.end: ; preds = %if.then, %entry + ret i32 %res +} + +; TABORT with register only. +define void @test_tabort1(i64 %val) { +; CHECK-LABEL: test_tabort1: +; CHECK: tabort 0(%r2) +; CHECK: br %r14 + call void @llvm.s390.tabort(i64 %val) + ret void +} + +; TABORT with immediate only. +define void @test_tabort2(i64 %val) { +; CHECK-LABEL: test_tabort2: +; CHECK: tabort 1234 +; CHECK: br %r14 + call void @llvm.s390.tabort(i64 1234) + ret void +} + +; TABORT with register + immediate. +define void @test_tabort3(i64 %val) { +; CHECK-LABEL: test_tabort3: +; CHECK: tabort 1234(%r2) +; CHECK: br %r14 + %sum = add i64 %val, 1234 + call void @llvm.s390.tabort(i64 %sum) + ret void +} + +; TABORT with out-of-range immediate. +define void @test_tabort4(i64 %val) { +; CHECK-LABEL: test_tabort4: +; CHECK: tabort 0({{%r[1-5]}}) +; CHECK: br %r14 + call void @llvm.s390.tabort(i64 4096) + ret void +} + +; NTSTG with base pointer only. +define void @test_ntstg1(i64 *%ptr, i64 %val) { +; CHECK-LABEL: test_ntstg1: +; CHECK: ntstg %r3, 0(%r2) +; CHECK: br %r14 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with base and index. +; Check that VSTL doesn't allow an index. +define void @test_ntstg2(i64 *%base, i64 %index, i64 %val) { +; CHECK-LABEL: test_ntstg2: +; CHECK: sllg [[REG:%r[1-5]]], %r3, 3 +; CHECK: ntstg %r4, 0([[REG]],%r2) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 %index + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with the highest in-range displacement. +define void @test_ntstg3(i64 *%base, i64 %val) { +; CHECK-LABEL: test_ntstg3: +; CHECK: ntstg %r3, 524280(%r2) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 65535 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with an out-of-range positive displacement. +define void @test_ntstg4(i64 *%base, i64 %val) { +; CHECK-LABEL: test_ntstg4: +; CHECK: ntstg %r3, 0({{%r[1-5]}}) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 65536 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with the lowest in-range displacement. +define void @test_ntstg5(i64 *%base, i64 %val) { +; CHECK-LABEL: test_ntstg5: +; CHECK: ntstg %r3, -524288(%r2) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 -65536 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; NTSTG with an out-of-range negative displacement. +define void @test_ntstg6(i64 *%base, i64 %val) { +; CHECK-LABEL: test_ntstg6: +; CHECK: ntstg %r3, 0({{%r[1-5]}}) +; CHECK: br %r14 + %ptr = getelementptr i64, i64 *%base, i64 -65537 + call void @llvm.s390.ntstg(i64 %val, i64 *%ptr) + ret void +} + +; ETND. +define i32 @test_etnd() { +; CHECK-LABEL: test_etnd: +; CHECK: etnd %r2 +; CHECK: br %r14 + %res = call i32 @llvm.s390.etnd() + ret i32 %res +} + +; PPA (Transaction-Abort Assist) +define void @test_ppa_txassist(i32 %val) { +; CHECK-LABEL: test_ppa_txassist: +; CHECK: ppa %r2, 0, 1 +; CHECK: br %r14 + call void @llvm.s390.ppa.txassist(i32 %val) + ret void +} + Index: llvm-head/test/MC/SystemZ/insn-bad-zEC12.s =================================================================== --- llvm-head.orig/test/MC/SystemZ/insn-bad-zEC12.s +++ llvm-head/test/MC/SystemZ/insn-bad-zEC12.s @@ -3,6 +3,22 @@ # RUN: FileCheck < %t %s #CHECK: error: invalid operand +#CHECK: ntstg %r0, -524289 +#CHECK: error: invalid operand +#CHECK: ntstg %r0, 524288 + + ntstg %r0, -524289 + ntstg %r0, 524288 + +#CHECK: error: invalid operand +#CHECK: ppa %r0, %r0, -1 +#CHECK: error: invalid operand +#CHECK: ppa %r0, %r0, 16 + + ppa %r0, %r0, -1 + ppa %r0, %r0, 16 + +#CHECK: error: invalid operand #CHECK: risbgn %r0,%r0,0,0,-1 #CHECK: error: invalid operand #CHECK: risbgn %r0,%r0,0,0,64 @@ -22,3 +38,47 @@ risbgn %r0,%r0,-1,0,0 risbgn %r0,%r0,256,0,0 +#CHECK: error: invalid operand +#CHECK: tabort -1 +#CHECK: error: invalid operand +#CHECK: tabort 4096 +#CHECK: error: invalid use of indexed addressing +#CHECK: tabort 0(%r1,%r2) + + tabort -1 + tabort 4096 + tabort 0(%r1,%r2) + +#CHECK: error: invalid operand +#CHECK: tbegin -1, 0 +#CHECK: error: invalid operand +#CHECK: tbegin 4096, 0 +#CHECK: error: invalid use of indexed addressing +#CHECK: tbegin 0(%r1,%r2), 0 +#CHECK: error: invalid operand +#CHECK: tbegin 0, -1 +#CHECK: error: invalid operand +#CHECK: tbegin 0, 65536 + + tbegin -1, 0 + tbegin 4096, 0 + tbegin 0(%r1,%r2), 0 + tbegin 0, -1 + tbegin 0, 65536 + +#CHECK: error: invalid operand +#CHECK: tbeginc -1, 0 +#CHECK: error: invalid operand +#CHECK: tbeginc 4096, 0 +#CHECK: error: invalid use of indexed addressing +#CHECK: tbeginc 0(%r1,%r2), 0 +#CHECK: error: invalid operand +#CHECK: tbeginc 0, -1 +#CHECK: error: invalid operand +#CHECK: tbeginc 0, 65536 + + tbeginc -1, 0 + tbeginc 4096, 0 + tbeginc 0(%r1,%r2), 0 + tbeginc 0, -1 + tbeginc 0, 65536 Index: llvm-head/test/MC/SystemZ/insn-good-zEC12.s =================================================================== --- llvm-head.orig/test/MC/SystemZ/insn-good-zEC12.s +++ llvm-head/test/MC/SystemZ/insn-good-zEC12.s @@ -1,6 +1,48 @@ # For zEC12 and above. # RUN: llvm-mc -triple s390x-linux-gnu -mcpu=zEC12 -show-encoding %s | FileCheck %s +#CHECK: etnd %r0 # encoding: [0xb2,0xec,0x00,0x00] +#CHECK: etnd %r15 # encoding: [0xb2,0xec,0x00,0xf0] +#CHECK: etnd %r7 # encoding: [0xb2,0xec,0x00,0x70] + + etnd %r0 + etnd %r15 + etnd %r7 + +#CHECK: ntstg %r0, -524288 # encoding: [0xe3,0x00,0x00,0x00,0x80,0x25] +#CHECK: ntstg %r0, -1 # encoding: [0xe3,0x00,0x0f,0xff,0xff,0x25] +#CHECK: ntstg %r0, 0 # encoding: [0xe3,0x00,0x00,0x00,0x00,0x25] +#CHECK: ntstg %r0, 1 # encoding: [0xe3,0x00,0x00,0x01,0x00,0x25] +#CHECK: ntstg %r0, 524287 # encoding: [0xe3,0x00,0x0f,0xff,0x7f,0x25] +#CHECK: ntstg %r0, 0(%r1) # encoding: [0xe3,0x00,0x10,0x00,0x00,0x25] +#CHECK: ntstg %r0, 0(%r15) # encoding: [0xe3,0x00,0xf0,0x00,0x00,0x25] +#CHECK: ntstg %r0, 524287(%r1,%r15) # encoding: [0xe3,0x01,0xff,0xff,0x7f,0x25] +#CHECK: ntstg %r0, 524287(%r15,%r1) # encoding: [0xe3,0x0f,0x1f,0xff,0x7f,0x25] +#CHECK: ntstg %r15, 0 # encoding: [0xe3,0xf0,0x00,0x00,0x00,0x25] + + ntstg %r0, -524288 + ntstg %r0, -1 + ntstg %r0, 0 + ntstg %r0, 1 + ntstg %r0, 524287 + ntstg %r0, 0(%r1) + ntstg %r0, 0(%r15) + ntstg %r0, 524287(%r1,%r15) + ntstg %r0, 524287(%r15,%r1) + ntstg %r15, 0 + +#CHECK: ppa %r0, %r0, 0 # encoding: [0xb2,0xe8,0x00,0x00] +#CHECK: ppa %r0, %r0, 15 # encoding: [0xb2,0xe8,0xf0,0x00] +#CHECK: ppa %r0, %r15, 0 # encoding: [0xb2,0xe8,0x00,0x0f] +#CHECK: ppa %r4, %r6, 7 # encoding: [0xb2,0xe8,0x70,0x46] +#CHECK: ppa %r15, %r0, 0 # encoding: [0xb2,0xe8,0x00,0xf0] + + ppa %r0, %r0, 0 + ppa %r0, %r0, 15 + ppa %r0, %r15, 0 + ppa %r4, %r6, 7 + ppa %r15, %r0, 0 + #CHECK: risbgn %r0, %r0, 0, 0, 0 # encoding: [0xec,0x00,0x00,0x00,0x00,0x59] #CHECK: risbgn %r0, %r0, 0, 0, 63 # encoding: [0xec,0x00,0x00,0x00,0x3f,0x59] #CHECK: risbgn %r0, %r0, 0, 255, 0 # encoding: [0xec,0x00,0x00,0xff,0x00,0x59] @@ -17,3 +59,68 @@ risbgn %r15,%r0,0,0,0 risbgn %r4,%r5,6,7,8 +#CHECK: tabort 0 # encoding: [0xb2,0xfc,0x00,0x00] +#CHECK: tabort 0(%r1) # encoding: [0xb2,0xfc,0x10,0x00] +#CHECK: tabort 0(%r15) # encoding: [0xb2,0xfc,0xf0,0x00] +#CHECK: tabort 4095 # encoding: [0xb2,0xfc,0x0f,0xff] +#CHECK: tabort 4095(%r1) # encoding: [0xb2,0xfc,0x1f,0xff] +#CHECK: tabort 4095(%r15) # encoding: [0xb2,0xfc,0xff,0xff] + + tabort 0 + tabort 0(%r1) + tabort 0(%r15) + tabort 4095 + tabort 4095(%r1) + tabort 4095(%r15) + +#CHECK: tbegin 0, 0 # encoding: [0xe5,0x60,0x00,0x00,0x00,0x00] +#CHECK: tbegin 4095, 0 # encoding: [0xe5,0x60,0x0f,0xff,0x00,0x00] +#CHECK: tbegin 0, 0 # encoding: [0xe5,0x60,0x00,0x00,0x00,0x00] +#CHECK: tbegin 0, 1 # encoding: [0xe5,0x60,0x00,0x00,0x00,0x01] +#CHECK: tbegin 0, 32767 # encoding: [0xe5,0x60,0x00,0x00,0x7f,0xff] +#CHECK: tbegin 0, 32768 # encoding: [0xe5,0x60,0x00,0x00,0x80,0x00] +#CHECK: tbegin 0, 65535 # encoding: [0xe5,0x60,0x00,0x00,0xff,0xff] +#CHECK: tbegin 0(%r1), 42 # encoding: [0xe5,0x60,0x10,0x00,0x00,0x2a] +#CHECK: tbegin 0(%r15), 42 # encoding: [0xe5,0x60,0xf0,0x00,0x00,0x2a] +#CHECK: tbegin 4095(%r1), 42 # encoding: [0xe5,0x60,0x1f,0xff,0x00,0x2a] +#CHECK: tbegin 4095(%r15), 42 # encoding: [0xe5,0x60,0xff,0xff,0x00,0x2a] + + tbegin 0, 0 + tbegin 4095, 0 + tbegin 0, 0 + tbegin 0, 1 + tbegin 0, 32767 + tbegin 0, 32768 + tbegin 0, 65535 + tbegin 0(%r1), 42 + tbegin 0(%r15), 42 + tbegin 4095(%r1), 42 + tbegin 4095(%r15), 42 + +#CHECK: tbeginc 0, 0 # encoding: [0xe5,0x61,0x00,0x00,0x00,0x00] +#CHECK: tbeginc 4095, 0 # encoding: [0xe5,0x61,0x0f,0xff,0x00,0x00] +#CHECK: tbeginc 0, 0 # encoding: [0xe5,0x61,0x00,0x00,0x00,0x00] +#CHECK: tbeginc 0, 1 # encoding: [0xe5,0x61,0x00,0x00,0x00,0x01] +#CHECK: tbeginc 0, 32767 # encoding: [0xe5,0x61,0x00,0x00,0x7f,0xff] +#CHECK: tbeginc 0, 32768 # encoding: [0xe5,0x61,0x00,0x00,0x80,0x00] +#CHECK: tbeginc 0, 65535 # encoding: [0xe5,0x61,0x00,0x00,0xff,0xff] +#CHECK: tbeginc 0(%r1), 42 # encoding: [0xe5,0x61,0x10,0x00,0x00,0x2a] +#CHECK: tbeginc 0(%r15), 42 # encoding: [0xe5,0x61,0xf0,0x00,0x00,0x2a] +#CHECK: tbeginc 4095(%r1), 42 # encoding: [0xe5,0x61,0x1f,0xff,0x00,0x2a] +#CHECK: tbeginc 4095(%r15), 42 # encoding: [0xe5,0x61,0xff,0xff,0x00,0x2a] + + tbeginc 0, 0 + tbeginc 4095, 0 + tbeginc 0, 0 + tbeginc 0, 1 + tbeginc 0, 32767 + tbeginc 0, 32768 + tbeginc 0, 65535 + tbeginc 0(%r1), 42 + tbeginc 0(%r15), 42 + tbeginc 4095(%r1), 42 + tbeginc 4095(%r15), 42 + +#CHECK: tend # encoding: [0xb2,0xf8,0x00,0x00] + + tend Index: llvm-head/test/MC/SystemZ/insn-bad-z196.s =================================================================== --- llvm-head.orig/test/MC/SystemZ/insn-bad-z196.s +++ llvm-head/test/MC/SystemZ/insn-bad-z196.s @@ -244,6 +244,11 @@ cxlgbr %f0, 16, %r0, 0 cxlgbr %f2, 0, %r0, 0 +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: etnd %r7 + + etnd %r7 + #CHECK: error: invalid operand #CHECK: fidbra %f0, 0, %f0, -1 #CHECK: error: invalid operand @@ -546,6 +551,16 @@ locr %r0,%r0,-1 locr %r0,%r0,16 +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: ntstg %r0, 524287(%r1,%r15) + + ntstg %r0, 524287(%r1,%r15) + +#CHECK: error: {{(instruction requires: processor-assist)?}} +#CHECK: ppa %r4, %r6, 7 + + ppa %r4, %r6, 7 + #CHECK: error: {{(instruction requires: miscellaneous-extensions)?}} #CHECK: risbgn %r1, %r2, 0, 0, 0 @@ -690,3 +705,24 @@ stocg %r0,-524289,1 stocg %r0,524288,1 stocg %r0,0(%r1,%r2),1 + +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: tabort 4095(%r1) + + tabort 4095(%r1) + +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: tbegin 4095(%r1), 42 + + tbegin 4095(%r1), 42 + +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: tbeginc 4095(%r1), 42 + + tbeginc 4095(%r1), 42 + +#CHECK: error: {{(instruction requires: transactional-execution)?}} +#CHECK: tend + + tend + Index: llvm-head/test/MC/Disassembler/SystemZ/insns.txt =================================================================== --- llvm-head.orig/test/MC/Disassembler/SystemZ/insns.txt +++ llvm-head/test/MC/Disassembler/SystemZ/insns.txt @@ -2503,6 +2503,15 @@ # CHECK: ear %r15, %a15 0xb2 0x4f 0x00 0xff +# CHECK: etnd %r0 +0xb2 0xec 0x00 0x00 + +# CHECK: etnd %r15 +0xb2 0xec 0x00 0xf0 + +# CHECK: etnd %r7 +0xb2 0xec 0x00 0x70 + # CHECK: fidbr %f0, 0, %f0 0xb3 0x5f 0x00 0x00 @@ -6034,6 +6043,36 @@ # CHECK: ny %r15, 0 0xe3 0xf0 0x00 0x00 0x00 0x54 +# CHECK: ntstg %r0, -524288 +0xe3 0x00 0x00 0x00 0x80 0x25 + +# CHECK: ntstg %r0, -1 +0xe3 0x00 0x0f 0xff 0xff 0x25 + +# CHECK: ntstg %r0, 0 +0xe3 0x00 0x00 0x00 0x00 0x25 + +# CHECK: ntstg %r0, 1 +0xe3 0x00 0x00 0x01 0x00 0x25 + +# CHECK: ntstg %r0, 524287 +0xe3 0x00 0x0f 0xff 0x7f 0x25 + +# CHECK: ntstg %r0, 0(%r1) +0xe3 0x00 0x10 0x00 0x00 0x25 + +# CHECK: ntstg %r0, 0(%r15) +0xe3 0x00 0xf0 0x00 0x00 0x25 + +# CHECK: ntstg %r0, 524287(%r1,%r15) +0xe3 0x01 0xff 0xff 0x7f 0x25 + +# CHECK: ntstg %r0, 524287(%r15,%r1) +0xe3 0x0f 0x1f 0xff 0x7f 0x25 + +# CHECK: ntstg %r15, 0 +0xe3 0xf0 0x00 0x00 0x00 0x25 + # CHECK: oc 0(1), 0 0xd6 0x00 0x00 0x00 0x00 0x00 @@ -6346,6 +6385,21 @@ # CHECK: popcnt %r7, %r8 0xb9 0xe1 0x00 0x78 +# CHECK: ppa %r0, %r0, 0 +0xb2 0xe8 0x00 0x00 + +# CHECK: ppa %r0, %r0, 15 +0xb2 0xe8 0xf0 0x00 + +# CHECK: ppa %r0, %r15, 0 +0xb2 0xe8 0x00 0x0f + +# CHECK: ppa %r4, %r6, 7 +0xb2 0xe8 0x70 0x46 + +# CHECK: ppa %r15, %r0, 0 +0xb2 0xe8 0x00 0xf0 + # CHECK: risbg %r0, %r0, 0, 0, 0 0xec 0x00 0x00 0x00 0x00 0x55 @@ -8062,6 +8116,93 @@ # CHECK: sy %r15, 0 0xe3 0xf0 0x00 0x00 0x00 0x5b +# CHECK: tabort 0 +0xb2 0xfc 0x00 0x00 + +# CHECK: tabort 0(%r1) +0xb2 0xfc 0x10 0x00 + +# CHECK: tabort 0(%r15) +0xb2 0xfc 0xf0 0x00 + +# CHECK: tabort 4095 +0xb2 0xfc 0x0f 0xff + +# CHECK: tabort 4095(%r1) +0xb2 0xfc 0x1f 0xff + +# CHECK: tabort 4095(%r15) +0xb2 0xfc 0xff 0xff + +# CHECK: tbegin 0, 0 +0xe5 0x60 0x00 0x00 0x00 0x00 + +# CHECK: tbegin 4095, 0 +0xe5 0x60 0x0f 0xff 0x00 0x00 + +# CHECK: tbegin 0, 0 +0xe5 0x60 0x00 0x00 0x00 0x00 + +# CHECK: tbegin 0, 1 +0xe5 0x60 0x00 0x00 0x00 0x01 + +# CHECK: tbegin 0, 32767 +0xe5 0x60 0x00 0x00 0x7f 0xff + +# CHECK: tbegin 0, 32768 +0xe5 0x60 0x00 0x00 0x80 0x00 + +# CHECK: tbegin 0, 65535 +0xe5 0x60 0x00 0x00 0xff 0xff + +# CHECK: tbegin 0(%r1), 42 +0xe5 0x60 0x10 0x00 0x00 0x2a + +# CHECK: tbegin 0(%r15), 42 +0xe5 0x60 0xf0 0x00 0x00 0x2a + +# CHECK: tbegin 4095(%r1), 42 +0xe5 0x60 0x1f 0xff 0x00 0x2a + +# CHECK: tbegin 4095(%r15), 42 +0xe5 0x60 0xff 0xff 0x00 0x2a + +# CHECK: tbeginc 0, 0 +0xe5 0x61 0x00 0x00 0x00 0x00 + +# CHECK: tbeginc 4095, 0 +0xe5 0x61 0x0f 0xff 0x00 0x00 + +# CHECK: tbeginc 0, 0 +0xe5 0x61 0x00 0x00 0x00 0x00 + +# CHECK: tbeginc 0, 1 +0xe5 0x61 0x00 0x00 0x00 0x01 + +# CHECK: tbeginc 0, 32767 +0xe5 0x61 0x00 0x00 0x7f 0xff + +# CHECK: tbeginc 0, 32768 +0xe5 0x61 0x00 0x00 0x80 0x00 + +# CHECK: tbeginc 0, 65535 +0xe5 0x61 0x00 0x00 0xff 0xff + +# CHECK: tbeginc 0(%r1), 42 +0xe5 0x61 0x10 0x00 0x00 0x2a + +# CHECK: tbeginc 0(%r15), 42 +0xe5 0x61 0xf0 0x00 0x00 0x2a + +# CHECK: tbeginc 4095(%r1), 42 +0xe5 0x61 0x1f 0xff 0x00 0x2a + +# CHECK: tbeginc 4095(%r15), 42 +0xe5 0x61 0xff 0xff 0x00 0x2a + +# CHECK: tend +0xb2 0xf8 0x00 0x00 + # CHECK: tm 0, 0 0x91 0x00 0x00 0x00 llvm-svn: 233803
2015-04-01 20:51:43 +08:00
case systemz: return "s390";
[SystemZ] Add llvm::Triple::systemz First step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. llvm-svn: 181007
2013-05-03 19:05:17 +08:00
Add llvm::Triple::getArchTypePrefix for getting the intrinsic prefix for an identifier architecture. llvm-svn: 79906
2009-08-24 17:53:06 +08:00
case x86:
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case x86_64: return "x86";
Create PTX backend. Patch by Che-Liang Chiou! llvm-svn: 113235
2010-09-08 02:14:24 +08:00
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case xcore: return "xcore";
Create PTX backend. Patch by Che-Liang Chiou! llvm-svn: 113235
2010-09-08 02:14:24 +08:00
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case nvptx: return "nvptx";
case nvptx64: return "nvptx";
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 18:18:08 +08:00
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case le32: return "le32";
Add support for le64. Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Depends on D5318. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5319 llvm-svn: 217697
2014-09-13 01:54:17 +08:00
case le64: return "le64";
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case amdil:
case amdil64: return "amdil";
case hsail:
case hsail64: return "hsail";
case spir:
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case spir64: return "spir";
Add the CSR company and the Kalimba DSP processor to Triple. Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
2014-07-11 01:26:54 +08:00
case kalimba: return "kalimba";
Add llvm::Triple::getArchTypePrefix for getting the intrinsic prefix for an identifier architecture. llvm-svn: 79906
2009-08-24 17:53:06 +08:00
}
}
Add llvm::Triple class for abstracting access to target triples. - The code is silly, I'm just amusing myself. Rewrite to be efficient if you like. :) Also, if you wish to debate the proper names of the triple components I'm all ears. llvm-svn: 68252
2009-04-02 05:53:23 +08:00
const char *Triple::getVendorTypeName(VendorType Kind) {
switch (Kind) {
case UnknownVendor: return "unknown";
case Apple: return "apple";
fix "pc" to be lower case in a target triple, patch by Yonggang Luo llvm-svn: 79016
2009-08-15 02:48:13 +08:00
case PC: return "pc";
Add scei vendor llvm-svn: 127705
2011-03-16 05:51:56 +08:00
case SCEI: return "scei";
Add triple support for the IBM BG/P and BG/Q supercomputers. llvm-svn: 153882
2012-04-03 02:31:33 +08:00
case BGP: return "bgp";
case BGQ: return "bgq";
Add the Freescale vendor to Triple. Adds the vendor 'fsl' (used by Freescale SDK) to Triple. This will allow clang support for Freescale cross-compile configurations. Patch by Tobias von Koch. llvm-svn: 162726
2012-08-28 10:10:30 +08:00
case Freescale: return "fsl";
Add powerpc-ibm-aix to Triple. Patch by Kai. llvm-svn: 165792
2012-10-12 19:08:57 +08:00
case IBM: return "ibm";
Add Imagination Technologies to the vendors in llvm::Triple Summary: This is a pre-requisite for supporting the mips-img-linux-gnu triple in clang. Differential Revision: http://reviews.llvm.org/D4435 llvm-svn: 212626
2014-07-10 00:03:10 +08:00
case ImaginationTechnologies: return "img";
Add MIPS Technologies to the vendors in llvm::Triple. This is a prerequisite for checking for 'mti' and 'img' in a consistent way in clang. Previously 'img' could use Triple::getVendor() but 'mti' could only use Triple::getVendorName(). llvm-svn: 213381
2014-07-18 22:28:19 +08:00
case MipsTechnologies: return "mti";
[NVPTX] Add support for selecting CUDA vs OCL mode based on triple IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl" llvm-svn: 184579
2013-06-22 02:51:49 +08:00
case NVIDIA: return "nvidia";
Add the CSR company and the Kalimba DSP processor to Triple. Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
2014-07-11 01:26:54 +08:00
case CSR: return "csr";
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
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148578
2012-01-21 05:51:11 +08:00
llvm_unreachable("Invalid VendorType!");
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
}
const char *Triple::getOSTypeName(OSType Kind) {
switch (Kind) {
case UnknownOS: return "unknown";
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
case CloudABI: return "cloudabi";
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
case Darwin: return "darwin";
Add llvm::triple constructor from arch, vendor, os strings, and recognize DragonFly OS type. llvm-svn: 72242
2009-05-22 10:24:11 +08:00
case DragonFly: return "dragonfly";
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
case FreeBSD: return "freebsd";
ADT/Triple: Add support for more explicit "osx" and "ios" OS names. llvm-svn: 129798
2011-04-20 04:19:27 +08:00
case IOS: return "ios";
Teach the Triple class about kfreebsd (FreeBSD kernel with a GNU userspace). llvm-svn: 136085
2011-07-26 23:30:04 +08:00
case KFreeBSD: return "kfreebsd";
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
case Linux: return "linux";
Add PS3 Triple class, Credit to John Thompson. llvm-svn: 89339
2009-11-19 19:59:00 +08:00
case Lv2: return "lv2";
ADT/Triple: Add support for Triple::MacOSX per feedback from Chris, will remove Triple::OSX once Clang has moved. llvm-svn: 129833
2011-04-20 07:34:12 +08:00
case MacOSX: return "macosx";
Add NetBSD to the Triple class, patch by Krister Walfridsson! llvm-svn: 75489
2009-07-14 04:22:23 +08:00
case NetBSD: return "netbsd";
Add triple for OpenBSD. llvm-svn: 74422
2009-06-29 21:36:13 +08:00
case OpenBSD: return "openbsd";
Add Triple matching for pic16 arch and solaris OS. - Patch by Yonggang Luo. llvm-svn: 79314
2009-08-18 12:43:27 +08:00
case Solaris: return "solaris";
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
case Win32: return "windows";
add haiku support, patch by Paul Davey! llvm-svn: 84238
2009-10-16 10:06:30 +08:00
case Haiku: return "haiku";
add some triple for minix, patch by Kees van Reeuwijk from PR7582 llvm-svn: 107785
2010-07-07 23:52:27 +08:00
case Minix: return "minix";
Add initial *-*-rtems* target, from Joel Sherrill llvm-svn: 134282
2011-07-02 06:41:06 +08:00
case RTEMS: return "rtems";
Make NaCl naming consistent. The triple OSType is called NaCl and is represented textually as NativeClient. Also added a link to the native client project for readers unfamiliar with it. A Clang patch will follow shortly. llvm-svn: 169291
2012-12-05 02:37:26 +08:00
case NaCl: return "nacl";
Add triple support for the IBM BG/P and BG/Q supercomputers. llvm-svn: 153882
2012-04-03 02:31:33 +08:00
case CNK: return "cnk";
Add support for the OpenBSD for Bitrig. Patch by David Hill. llvm-svn: 161344
2012-08-07 04:52:18 +08:00
case Bitrig: return "bitrig";
Add powerpc-ibm-aix to Triple. Patch by Kai. llvm-svn: 165792
2012-10-12 19:08:57 +08:00
case AIX: return "aix";
[NVPTX] Add support for selecting CUDA vs OCL mode based on triple IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl" llvm-svn: 184579
2013-06-22 02:51:49 +08:00
case CUDA: return "cuda";
case NVCL: return "nvcl";
Triple: Add AMDHSA operating system type This operating system type represents the AMD HSA runtime, and will be required by the R600 backend in order to generate correct code for this runtime. llvm-svn: 223124
2014-12-03 00:45:47 +08:00
case AMDHSA: return "amdhsa";
Add the triple for the Sony Playstation®4. Lots more to follow. llvm-svn: 227060
2015-01-26 06:46:59 +08:00
case PS4: return "ps4";
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
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148578
2012-01-21 05:51:11 +08:00
llvm_unreachable("Invalid OSType");
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 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
const char *Triple::getEnvironmentTypeName(EnvironmentType Kind) {
switch (Kind) {
case UnknownEnvironment: return "unknown";
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
case GNU: return "gnu";
Add support for the gnueabihf environment. Patch by Sylvestre Ledru. llvm-svn: 148434
2012-01-19 07:35:29 +08:00
case GNUEABIHF: return "gnueabihf";
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
case GNUEABI: return "gnueabi";
Initial patch for x32 ABI support. Add the x32 environment kind to the triple, and separate the concept of pointer size and callee save stack slot size, since they're not equal on x32. llvm-svn: 173175
2013-01-23 02:02:49 +08:00
case GNUX32: return "gnux32";
[x86] Support i386-*-*-code16 triple for emitting 16-bit code llvm-svn: 199648
2014-01-20 20:02:25 +08:00
case CODE16: return "code16";
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
case EABI: return "eabi";
Recognize EABIHF as environment and use it for RTAPI + VFP. llvm-svn: 197405
2013-12-17 02:51:28 +08:00
case EABIHF: return "eabihf";
Rename ANDROIDEABI to Android. Most of the code guarded with ANDROIDEABI are not ARM-specific, and having no relation with arm-eabi. Thus, it will be more natural to call this environment "Android" instead of "ANDROIDEABI". Note: We are not using ANDROID because several projects are using "-DANDROID" as the conditional compilation flag. llvm-svn: 163087
2012-09-02 17:29:46 +08:00
case Android: return "android";
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
case MSVC: return "msvc";
case Itanium: return "itanium";
case Cygnus: return "cygnus";
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
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148578
2012-01-21 05:51:11 +08:00
llvm_unreachable("Invalid EnvironmentType!");
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
}
Pass StringRef by value. llvm-svn: 86251
2009-11-06 18:58:06 +08:00
Triple::ArchType Triple::getArchTypeForLLVMName(StringRef Name) {
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
return StringSwitch<Triple::ArchType>(Name)
Add AArch64 as an experimental target. This patch adds support for AArch64 (ARM's 64-bit architecture) to LLVM in the "experimental" category. Currently, it won't be built unless requested explicitly. This initial commit should have support for: + Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions (except the late addition CRC instructions). + CodeGen features required for C++03 and C99. + Compilation for the "small" memory model: code+static data < 4GB. + Absolute and position-independent code. + GNU-style (i.e. "__thread") TLS. + Debugging information. The principal omission, currently, is performance tuning. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174054
2013-01-31 20:12:40 +08:00
.Case("aarch64", aarch64)
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
.Case("aarch64_be", aarch64_be)
AArch64: remove arm64 triple enumerator. Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and invites bugs where only one is checked. In reality, the only legitimate difference between the two (arm64 usually means iOS) is also present in the OS part of the triple and that's what should be checked. We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so there aren't any LLVM-side test changes. llvm-svn: 213743
2014-07-23 20:32:47 +08:00
.Case("arm64", aarch64) // "arm64" is an alias for "aarch64"
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
.Case("arm", arm)
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
.Case("armeb", armeb)
BPF backend Summary: V8->V9: - cleanup tests V7->V8: - addressed feedback from David: - switched to range-based 'for' loops - fixed formatting of tests V6->V7: - rebased and adjusted AsmPrinter args - CamelCased .td, fixed formatting, cleaned up names, removed unused patterns - diffstat: 3 files changed, 203 insertions(+), 227 deletions(-) V5->V6: - addressed feedback from Chandler: - reinstated full verbose standard banner in all files - fixed variables that were not in CamelCase - fixed names of #ifdef in header files - removed redundant braces in if/else chains with single statements - fixed comments - removed trailing empty line - dropped debug annotations from tests - diffstat of these changes: 46 files changed, 456 insertions(+), 469 deletions(-) V4->V5: - fix setLoadExtAction() interface - clang-formated all where it made sense V3->V4: - added CODE_OWNERS entry for BPF backend V2->V3: - fix metadata in tests V1->V2: - addressed feedback from Tom and Matt - removed top level change to configure (now everything via 'experimental-backend') - reworked error reporting via DiagnosticInfo (similar to R600) - added few more tests - added cmake build - added Triple::bpf - tested on linux and darwin V1 cover letter: --------------------- recently linux gained "universal in-kernel virtual machine" which is called eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since new instruction set is based on it. This patch adds a new backend that emits extended BPF instruction set. The concept and development are covered by the following articles: http://lwn.net/Articles/599755/ http://lwn.net/Articles/575531/ http://lwn.net/Articles/603983/ http://lwn.net/Articles/606089/ http://lwn.net/Articles/612878/ One of use cases: dtrace/systemtap alternative. bpf syscall manpage: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe instruction set description and differences vs classic BPF: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt Short summary of instruction set: - 64-bit registers R0 - return value from in-kernel function, and exit value for BPF program R1 - R5 - arguments from BPF program to in-kernel function R6 - R9 - callee saved registers that in-kernel function will preserve R10 - read-only frame pointer to access stack - two-operand instructions like +, -, *, mov, load/store - implicit prologue/epilogue (invisible stack pointer) - no floating point, no simd Short history of extended BPF in kernel: interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future. It's a very small and simple backend. There is no support for global variables, arbitrary function calls, floating point, varargs, exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc. From C front-end point of view it's very restricted. It's done on purpose, since kernel rejects all programs that it cannot prove safe. It rejects programs with loops and with memory accesses via arbitrary pointers. When kernel accepts the program it is guaranteed that program will terminate and will not crash the kernel. This patch implements all 'must have' bits. There are several things on TODO list, so this is not the end of development. Most of the code is a boiler plate code, copy-pasted from other backends. Only odd things are lack or < and <= instructions, specialized load_byte intrinsics and 'compare and goto' as single instruction. Current instruction set is fixed, but more instructions can be added in the future. Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D6494 llvm-svn: 227008
2015-01-25 01:51:26 +08:00
.Case("bpf", bpf)
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
.Case("mips", mips)
.Case("mipsel", mipsel)
.Case("mips64", mips64)
.Case("mips64el", mips64el)
.Case("msp430", msp430)
.Case("ppc64", ppc64)
.Case("ppc32", ppc)
.Case("ppc", ppc)
[PowerPC] Support powerpc64le as a syntax-checking target. This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
2013-07-26 09:35:43 +08:00
.Case("ppc64le", ppc64le)
Add support for r600 (AMD GPUs HD2XXX - HD6XXX) target triplet. Patch by Tom Stellard! llvm-svn: 152400
2012-03-09 18:09:36 +08:00
.Case("r600", r600)
Triple: Add amdgcn triple This will be used for AMD GPUs with the Graphics Core Next architecture, which are currently using by the r600 triple. llvm-svn: 225276
2015-01-07 02:00:00 +08:00
.Case("amdgcn", amdgcn)
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
.Case("hexagon", hexagon)
.Case("sparc", sparc)
.Case("sparcv9", sparcv9)
[SystemZ] Add llvm::Triple::systemz First step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. llvm-svn: 181007
2013-05-03 19:05:17 +08:00
.Case("systemz", systemz)
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
.Case("tce", tce)
.Case("thumb", thumb)
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
.Case("thumbeb", thumbeb)
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
.Case("x86", x86)
.Case("x86-64", x86_64)
.Case("xcore", xcore)
This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it. The new target machines are: nvptx (old ptx32) => 32-bit PTX nvptx64 (old ptx64) => 64-bit PTX The sources are based on the internal NVIDIA NVPTX back-end, and contain more functionality than the current PTX back-end currently provides. NV_CONTRIB llvm-svn: 156196
2012-05-05 04:18:50 +08:00
.Case("nvptx", nvptx)
.Case("nvptx64", nvptx64)
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
.Case("le32", le32)
Add support for le64. Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Depends on D5318. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5319 llvm-svn: 217697
2014-09-13 01:54:17 +08:00
.Case("le64", le64)
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
.Case("amdil", amdil)
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
.Case("amdil64", amdil64)
.Case("hsail", hsail)
.Case("hsail64", hsail64)
Add in support for SPIR to LLVM core. This adds a new target and two new calling conventions. llvm-svn: 164948
2012-10-02 01:01:31 +08:00
.Case("spir", spir)
Add support for SPIR64 target - the 64bit counterpart of SPIR. The new OpenCL SPIR extension spec will define separate SPIR for 32 and 64 bit architectures. llvm-svn: 168036
2012-11-15 18:35:47 +08:00
.Case("spir64", spir64)
Add the CSR company and the Kalimba DSP processor to Triple. Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
2014-07-11 01:26:54 +08:00
.Case("kalimba", kalimba)
Switch a bunch of manual if-chains to use StringSwitch. Clean them up in the process. Some of these are still a bit gross. Still, this cuts 80 some lines out of this ridiculous file. ;] llvm-svn: 150331
2012-02-12 17:27:38 +08:00
.Default(UnknownArch);
Pass target triple string in to TargetMachine constructor. This is not just a matter of passing in the target triple from the module; currently backends are making decisions based on the build and host architecture. The goal is to migrate to making these decisions based off of the triple (in conjunction with the feature string). Thus most clients pass in the target triple, or the host triple if that is empty. This has one important change in the way behavior of the JIT and llc. For the JIT, it was previously selecting the Target based on the host (naturally), but it was setting the target machine features based on the triple from the module. Now it is setting the target machine features based on the triple of the host. For LLC, -march was previously only used to select the target, the target machine features were initialized from the module's triple (which may have been empty). Now the target triple is taken from the module, or the host's triple is used if that is empty. Then the triple is adjusted to match -march. The take away is that -march for llc is now used in conjunction with the host triple to initialize the subtarget. If users want more deterministic behavior from llc, they should use -mtriple, or set the triple in the input module. llvm-svn: 77946
2009-08-03 12:03:51 +08:00
}
Fix ARM triple parsing The triple parser should only accept existing architecture names when the triple starts with armv, armebv, thumbv or thumbebv. Patch by Gabor Ballabas. llvm-svn: 222129
2014-11-17 22:08:57 +08:00
static Triple::ArchType parseARMArch(StringRef ArchName) {
size_t offset = StringRef::npos;
Triple::ArchType arch = Triple::UnknownArch;
bool isThumb = ArchName.startswith("thumb");
if (ArchName.equals("arm"))
return Triple::arm;
if (ArchName.equals("armeb"))
return Triple::armeb;
if (ArchName.equals("thumb"))
return Triple::thumb;
if (ArchName.equals("thumbeb"))
return Triple::thumbeb;
if (ArchName.equals("arm64") || ArchName.equals("aarch64"))
return Triple::aarch64;
if (ArchName.equals("aarch64_be"))
return Triple::aarch64_be;
if (ArchName.startswith("armv")) {
offset = 3;
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
if (ArchName.endswith("eb")) {
arch = Triple::armeb;
ArchName = ArchName.substr(0, ArchName.size() - 2);
} else
arch = Triple::arm;
Fix ARM triple parsing The triple parser should only accept existing architecture names when the triple starts with armv, armebv, thumbv or thumbebv. Patch by Gabor Ballabas. llvm-svn: 222129
2014-11-17 22:08:57 +08:00
} else if (ArchName.startswith("armebv")) {
offset = 5;
arch = Triple::armeb;
} else if (ArchName.startswith("thumbv")) {
offset = 5;
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
if (ArchName.endswith("eb")) {
arch = Triple::thumbeb;
ArchName = ArchName.substr(0, ArchName.size() - 2);
} else
arch = Triple::thumb;
Fix ARM triple parsing The triple parser should only accept existing architecture names when the triple starts with armv, armebv, thumbv or thumbebv. Patch by Gabor Ballabas. llvm-svn: 222129
2014-11-17 22:08:57 +08:00
} else if (ArchName.startswith("thumbebv")) {
offset = 7;
arch = Triple::thumbeb;
}
return StringSwitch<Triple::ArchType>(ArchName.substr(offset))
.Cases("v2", "v2a", isThumb ? Triple::UnknownArch : arch)
.Cases("v3", "v3m", isThumb ? Triple::UnknownArch : arch)
.Cases("v4", "v4t", arch)
.Cases("v5", "v5e", "v5t", "v5te", "v5tej", arch)
[ARM] Add armv6s[-]m as an alias to armv6[-]m llvm-svn: 228696
2015-02-10 23:15:08 +08:00
.Cases("v6", "v6j", "v6k", "v6m", "v6sm", arch)
Fix ARM triple parsing The triple parser should only accept existing architecture names when the triple starts with armv, armebv, thumbv or thumbebv. Patch by Gabor Ballabas. llvm-svn: 222129
2014-11-17 22:08:57 +08:00
.Cases("v6t2", "v6z", "v6zk", arch)
.Cases("v7", "v7a", "v7em", "v7l", arch)
.Cases("v7m", "v7r", "v7s", arch)
.Cases("v8", "v8a", arch)
[AArch64, ARM] Add v8.1a architecture and generic cpu New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: t.p.northover Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8505 llvm-svn: 233290
2015-03-27 01:05:54 +08:00
.Cases("v8.1", "v8.1a", arch)
Fix ARM triple parsing The triple parser should only accept existing architecture names when the triple starts with armv, armebv, thumbv or thumbebv. Patch by Gabor Ballabas. llvm-svn: 222129
2014-11-17 22:08:57 +08:00
.Default(Triple::UnknownArch);
}
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
static Triple::ArchType parseArch(StringRef ArchName) {
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::ArchType ARMArch(parseARMArch(ArchName));
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
return StringSwitch<Triple::ArchType>(ArchName)
.Cases("i386", "i486", "i586", "i686", Triple::x86)
// FIXME: Do we need to support these?
.Cases("i786", "i886", "i986", Triple::x86)
X86: Encode the 'h' cpu subtype in the MachO header for x86. llvm-svn: 194906
2013-11-16 08:52:57 +08:00
.Cases("amd64", "x86_64", "x86_64h", Triple::x86_64)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Case("powerpc", Triple::ppc)
.Cases("powerpc64", "ppu", Triple::ppc64)
[PowerPC] Support powerpc64le as a syntax-checking target. This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
2013-07-26 09:35:43 +08:00
.Case("powerpc64le", Triple::ppc64le)
Fix ARM triple parsing The triple parser should only accept existing architecture names when the triple starts with armv, armebv, thumbv or thumbebv. Patch by Gabor Ballabas. llvm-svn: 222129
2014-11-17 22:08:57 +08:00
.Case("xscale", Triple::arm)
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
.Case("xscaleeb", Triple::armeb)
.StartsWith("arm", ARMArch)
.StartsWith("thumb", ARMArch)
.StartsWith("aarch64", ARMArch)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Case("msp430", Triple::msp430)
.Cases("mips", "mipseb", "mipsallegrex", Triple::mips)
Support was removed from LLVM's MIPS backend for the PSP variant of that chip in r139383, and the PSP components of the triple are really annoying to parse. Let's leave this chapter behind. There is no reason to expect LLVM to see a PSP-related triple these days, and so no reasonable motivation to support them. It might be reasonable to prune a few of the older MIPS triple forms in general, but as those at least cause no burden on parsing (they aren't both a chip and an OS!), I'm happy to leave them in for now. llvm-svn: 151156
2012-02-22 19:32:54 +08:00
.Cases("mipsel", "mipsallegrexel", Triple::mipsel)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Cases("mips64", "mips64eb", Triple::mips64)
.Case("mips64el", Triple::mips64el)
Add support for r600 (AMD GPUs HD2XXX - HD6XXX) target triplet. Patch by Tom Stellard! llvm-svn: 152400
2012-03-09 18:09:36 +08:00
.Case("r600", Triple::r600)
Triple: Add amdgcn triple This will be used for AMD GPUs with the Graphics Core Next architecture, which are currently using by the r600 triple. llvm-svn: 225276
2015-01-07 02:00:00 +08:00
.Case("amdgcn", Triple::amdgcn)
BPF backend Summary: V8->V9: - cleanup tests V7->V8: - addressed feedback from David: - switched to range-based 'for' loops - fixed formatting of tests V6->V7: - rebased and adjusted AsmPrinter args - CamelCased .td, fixed formatting, cleaned up names, removed unused patterns - diffstat: 3 files changed, 203 insertions(+), 227 deletions(-) V5->V6: - addressed feedback from Chandler: - reinstated full verbose standard banner in all files - fixed variables that were not in CamelCase - fixed names of #ifdef in header files - removed redundant braces in if/else chains with single statements - fixed comments - removed trailing empty line - dropped debug annotations from tests - diffstat of these changes: 46 files changed, 456 insertions(+), 469 deletions(-) V4->V5: - fix setLoadExtAction() interface - clang-formated all where it made sense V3->V4: - added CODE_OWNERS entry for BPF backend V2->V3: - fix metadata in tests V1->V2: - addressed feedback from Tom and Matt - removed top level change to configure (now everything via 'experimental-backend') - reworked error reporting via DiagnosticInfo (similar to R600) - added few more tests - added cmake build - added Triple::bpf - tested on linux and darwin V1 cover letter: --------------------- recently linux gained "universal in-kernel virtual machine" which is called eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since new instruction set is based on it. This patch adds a new backend that emits extended BPF instruction set. The concept and development are covered by the following articles: http://lwn.net/Articles/599755/ http://lwn.net/Articles/575531/ http://lwn.net/Articles/603983/ http://lwn.net/Articles/606089/ http://lwn.net/Articles/612878/ One of use cases: dtrace/systemtap alternative. bpf syscall manpage: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe instruction set description and differences vs classic BPF: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt Short summary of instruction set: - 64-bit registers R0 - return value from in-kernel function, and exit value for BPF program R1 - R5 - arguments from BPF program to in-kernel function R6 - R9 - callee saved registers that in-kernel function will preserve R10 - read-only frame pointer to access stack - two-operand instructions like +, -, *, mov, load/store - implicit prologue/epilogue (invisible stack pointer) - no floating point, no simd Short history of extended BPF in kernel: interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future. It's a very small and simple backend. There is no support for global variables, arbitrary function calls, floating point, varargs, exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc. From C front-end point of view it's very restricted. It's done on purpose, since kernel rejects all programs that it cannot prove safe. It rejects programs with loops and with memory accesses via arbitrary pointers. When kernel accepts the program it is guaranteed that program will terminate and will not crash the kernel. This patch implements all 'must have' bits. There are several things on TODO list, so this is not the end of development. Most of the code is a boiler plate code, copy-pasted from other backends. Only odd things are lack or < and <= instructions, specialized load_byte intrinsics and 'compare and goto' as single instruction. Current instruction set is fixed, but more instructions can be added in the future. Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D6494 llvm-svn: 227008
2015-01-25 01:51:26 +08:00
.Case("bpf", Triple::bpf)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Case("hexagon", Triple::hexagon)
[SystemZ] Add llvm::Triple::systemz First step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. llvm-svn: 181007
2013-05-03 19:05:17 +08:00
.Case("s390x", Triple::systemz)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Case("sparc", Triple::sparc)
Recognize sparc64 as an alias for sparcv9 triples. Patch by Brad Smith! llvm-svn: 181808
2013-05-15 01:47:27 +08:00
.Cases("sparcv9", "sparc64", Triple::sparcv9)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Case("tce", Triple::tce)
.Case("xcore", Triple::xcore)
This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it. The new target machines are: nvptx (old ptx32) => 32-bit PTX nvptx64 (old ptx64) => 64-bit PTX The sources are based on the internal NVIDIA NVPTX back-end, and contain more functionality than the current PTX back-end currently provides. NV_CONTRIB llvm-svn: 156196
2012-05-05 04:18:50 +08:00
.Case("nvptx", Triple::nvptx)
.Case("nvptx64", Triple::nvptx64)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Case("le32", Triple::le32)
Add support for le64. Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Depends on D5318. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5319 llvm-svn: 217697
2014-09-13 01:54:17 +08:00
.Case("le64", Triple::le64)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Case("amdil", Triple::amdil)
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
.Case("amdil64", Triple::amdil64)
.Case("hsail", Triple::hsail)
.Case("hsail64", Triple::hsail64)
Add in support for SPIR to LLVM core. This adds a new target and two new calling conventions. llvm-svn: 164948
2012-10-02 01:01:31 +08:00
.Case("spir", Triple::spir)
Add support for SPIR64 target - the 64bit counterpart of SPIR. The new OpenCL SPIR extension spec will define separate SPIR for 32 and 64 bit architectures. llvm-svn: 168036
2012-11-15 18:35:47 +08:00
.Case("spir64", Triple::spir64)
Adding kalimba variants as Triple sub-architectures. Reviewed in: http://reviews.llvm.org/D5115 llvm-svn: 217229
2014-09-05 14:46:43 +08:00
.StartsWith("kalimba", Triple::kalimba)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Default(Triple::UnknownArch);
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
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
static Triple::VendorType parseVendor(StringRef VendorName) {
return StringSwitch<Triple::VendorType>(VendorName)
.Case("apple", Triple::Apple)
.Case("pc", Triple::PC)
.Case("scei", Triple::SCEI)
Add triple support for the IBM BG/P and BG/Q supercomputers. llvm-svn: 153882
2012-04-03 02:31:33 +08:00
.Case("bgp", Triple::BGP)
.Case("bgq", Triple::BGQ)
Add the Freescale vendor to Triple. Adds the vendor 'fsl' (used by Freescale SDK) to Triple. This will allow clang support for Freescale cross-compile configurations. Patch by Tobias von Koch. llvm-svn: 162726
2012-08-28 10:10:30 +08:00
.Case("fsl", Triple::Freescale)
Add powerpc-ibm-aix to Triple. Patch by Kai. llvm-svn: 165792
2012-10-12 19:08:57 +08:00
.Case("ibm", Triple::IBM)
Add Imagination Technologies to the vendors in llvm::Triple Summary: This is a pre-requisite for supporting the mips-img-linux-gnu triple in clang. Differential Revision: http://reviews.llvm.org/D4435 llvm-svn: 212626
2014-07-10 00:03:10 +08:00
.Case("img", Triple::ImaginationTechnologies)
Add MIPS Technologies to the vendors in llvm::Triple. This is a prerequisite for checking for 'mti' and 'img' in a consistent way in clang. Previously 'img' could use Triple::getVendor() but 'mti' could only use Triple::getVendorName(). llvm-svn: 213381
2014-07-18 22:28:19 +08:00
.Case("mti", Triple::MipsTechnologies)
[NVPTX] Add support for selecting CUDA vs OCL mode based on triple IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl" llvm-svn: 184579
2013-06-22 02:51:49 +08:00
.Case("nvidia", Triple::NVIDIA)
Add the CSR company and the Kalimba DSP processor to Triple. Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
2014-07-11 01:26:54 +08:00
.Case("csr", Triple::CSR)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Default(Triple::UnknownVendor);
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
}
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
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
static Triple::OSType parseOS(StringRef OSName) {
return StringSwitch<Triple::OSType>(OSName)
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
.StartsWith("cloudabi", Triple::CloudABI)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.StartsWith("darwin", Triple::Darwin)
.StartsWith("dragonfly", Triple::DragonFly)
.StartsWith("freebsd", Triple::FreeBSD)
.StartsWith("ios", Triple::IOS)
.StartsWith("kfreebsd", Triple::KFreeBSD)
.StartsWith("linux", Triple::Linux)
.StartsWith("lv2", Triple::Lv2)
.StartsWith("macosx", Triple::MacOSX)
.StartsWith("netbsd", Triple::NetBSD)
.StartsWith("openbsd", Triple::OpenBSD)
.StartsWith("solaris", Triple::Solaris)
.StartsWith("win32", Triple::Win32)
Canonicalise Windows target triple spellings Construct a uniform Windows target triple nomenclature which is congruent to the Linux counterpart. The old triples are normalised to the new canonical form. This cleans up the long-standing issue of odd naming for various Windows environments. There are four different environments on Windows: MSVC: The MS ABI, MSVCRT environment as defined by Microsoft GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries Itanium: The MSVCRT environment + libc++ built with Itanium ABI Cygnus: The Cygwin environment which uses custom libraries for everything The following spellings are now written as: i686-pc-win32 => i686-pc-windows-msvc i686-pc-mingw32 => i686-pc-windows-gnu i686-pc-cygwin => i686-pc-windows-cygnus This should be sufficiently flexible to allow us to target other windows environments in the future as necessary. llvm-svn: 204977
2014-03-28 06:50:05 +08:00
.StartsWith("windows", Triple::Win32)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.StartsWith("haiku", Triple::Haiku)
.StartsWith("minix", Triple::Minix)
.StartsWith("rtems", Triple::RTEMS)
Make NaCl naming consistent. The triple OSType is called NaCl and is represented textually as NativeClient. Also added a link to the native client project for readers unfamiliar with it. A Clang patch will follow shortly. llvm-svn: 169291
2012-12-05 02:37:26 +08:00
.StartsWith("nacl", Triple::NaCl)
Add triple support for the IBM BG/P and BG/Q supercomputers. llvm-svn: 153882
2012-04-03 02:31:33 +08:00
.StartsWith("cnk", Triple::CNK)
Add support for the OpenBSD for Bitrig. Patch by David Hill. llvm-svn: 161344
2012-08-07 04:52:18 +08:00
.StartsWith("bitrig", Triple::Bitrig)
Add powerpc-ibm-aix to Triple. Patch by Kai. llvm-svn: 165792
2012-10-12 19:08:57 +08:00
.StartsWith("aix", Triple::AIX)
[NVPTX] Add support for selecting CUDA vs OCL mode based on triple IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl" llvm-svn: 184579
2013-06-22 02:51:49 +08:00
.StartsWith("cuda", Triple::CUDA)
.StartsWith("nvcl", Triple::NVCL)
Triple: Add AMDHSA operating system type This operating system type represents the AMD HSA runtime, and will be required by the R600 backend in order to generate correct code for this runtime. llvm-svn: 223124
2014-12-03 00:45:47 +08:00
.StartsWith("amdhsa", Triple::AMDHSA)
Add the triple for the Sony Playstation®4. Lots more to follow. llvm-svn: 227060
2015-01-26 06:46:59 +08:00
.StartsWith("ps4", Triple::PS4)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Default(Triple::UnknownOS);
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
}
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
static Triple::EnvironmentType parseEnvironment(StringRef EnvironmentName) {
return StringSwitch<Triple::EnvironmentType>(EnvironmentName)
Recognize EABIHF as environment and use it for RTAPI + VFP. llvm-svn: 197405
2013-12-17 02:51:28 +08:00
.StartsWith("eabihf", Triple::EABIHF)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.StartsWith("eabi", Triple::EABI)
.StartsWith("gnueabihf", Triple::GNUEABIHF)
.StartsWith("gnueabi", Triple::GNUEABI)
Initial patch for x32 ABI support. Add the x32 environment kind to the triple, and separate the concept of pointer size and callee save stack slot size, since they're not equal on x32. llvm-svn: 173175
2013-01-23 02:02:49 +08:00
.StartsWith("gnux32", Triple::GNUX32)
[x86] Support i386-*-*-code16 triple for emitting 16-bit code llvm-svn: 199648
2014-01-20 20:02:25 +08:00
.StartsWith("code16", Triple::CODE16)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.StartsWith("gnu", Triple::GNU)
Rename ANDROIDEABI to Android. Most of the code guarded with ANDROIDEABI are not ARM-specific, and having no relation with arm-eabi. Thus, it will be more natural to call this environment "Android" instead of "ANDROIDEABI". Note: We are not using ANDROID because several projects are using "-DANDROID" as the conditional compilation flag. llvm-svn: 163087
2012-09-02 17:29:46 +08:00
.StartsWith("android", Triple::Android)
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
.StartsWith("msvc", Triple::MSVC)
.StartsWith("itanium", Triple::Itanium)
.StartsWith("cygnus", Triple::Cygnus)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
.Default(Triple::UnknownEnvironment);
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
}
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
static Triple::ObjectFormatType parseFormat(StringRef EnvironmentName) {
return StringSwitch<Triple::ObjectFormatType>(EnvironmentName)
.EndsWith("coff", Triple::COFF)
.EndsWith("elf", Triple::ELF)
.EndsWith("macho", Triple::MachO)
.Default(Triple::UnknownObjectFormat);
}
Refactor ARM subarchitecture parsing Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
2014-07-18 20:00:48 +08:00
static Triple::SubArchType parseSubArch(StringRef SubArchName) {
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
if (SubArchName.endswith("eb"))
SubArchName = SubArchName.substr(0, SubArchName.size() - 2);
Refactor ARM subarchitecture parsing Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
2014-07-18 20:00:48 +08:00
return StringSwitch<Triple::SubArchType>(SubArchName)
[AArch64, ARM] Add v8.1a architecture and generic cpu New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: t.p.northover Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8505 llvm-svn: 233290
2015-03-27 01:05:54 +08:00
.EndsWith("v8.1a", Triple::ARMSubArch_v8_1a)
Refactor ARM subarchitecture parsing Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
2014-07-18 20:00:48 +08:00
.EndsWith("v8", Triple::ARMSubArch_v8)
.EndsWith("v8a", Triple::ARMSubArch_v8)
.EndsWith("v7", Triple::ARMSubArch_v7)
.EndsWith("v7a", Triple::ARMSubArch_v7)
.EndsWith("v7em", Triple::ARMSubArch_v7em)
.EndsWith("v7l", Triple::ARMSubArch_v7)
.EndsWith("v7m", Triple::ARMSubArch_v7m)
.EndsWith("v7r", Triple::ARMSubArch_v7)
.EndsWith("v7s", Triple::ARMSubArch_v7s)
.EndsWith("v6", Triple::ARMSubArch_v6)
.EndsWith("v6m", Triple::ARMSubArch_v6m)
[ARM] Add armv6s[-]m as an alias to armv6[-]m llvm-svn: 228696
2015-02-10 23:15:08 +08:00
.EndsWith("v6sm", Triple::ARMSubArch_v6m)
[ARM] Add support for ARMV6K subtarget (LLVM) ARMv6K is another layer between ARMV6 and ARMV6T2. This is the LLVM side of the changes. ARMV6 family LLVM implementation. +-------------------------------------+ | ARMV6 | +----------------+--------------------+ | ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors +----------------+--------------------+ have support for hint instructions | ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can +-------------------------------------+ be either real or default to NOP. | ARMV7 (arm,thumb,thumb2) | The two processors also use +-------------------------------------+ different encoding for them. Patch by Vinicius Tinti. llvm-svn: 232468
2015-03-17 19:55:28 +08:00
.EndsWith("v6k", Triple::ARMSubArch_v6k)
Refactor ARM subarchitecture parsing Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
2014-07-18 20:00:48 +08:00
.EndsWith("v6t2", Triple::ARMSubArch_v6t2)
.EndsWith("v5", Triple::ARMSubArch_v5)
.EndsWith("v5e", Triple::ARMSubArch_v5)
.EndsWith("v5t", Triple::ARMSubArch_v5)
.EndsWith("v5te", Triple::ARMSubArch_v5te)
.EndsWith("v4t", Triple::ARMSubArch_v4t)
Adding kalimba variants as Triple sub-architectures. Reviewed in: http://reviews.llvm.org/D5115 llvm-svn: 217229
2014-09-05 14:46:43 +08:00
.EndsWith("kalimba3", Triple::KalimbaSubArch_v3)
.EndsWith("kalimba4", Triple::KalimbaSubArch_v4)
.EndsWith("kalimba5", Triple::KalimbaSubArch_v5)
Refactor ARM subarchitecture parsing Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
2014-07-18 20:00:48 +08:00
.Default(Triple::NoSubArch);
}
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
static const char *getObjectFormatTypeName(Triple::ObjectFormatType Kind) {
switch (Kind) {
case Triple::UnknownObjectFormat: return "";
case Triple::COFF: return "coff";
case Triple::ELF: return "elf";
case Triple::MachO: return "macho";
}
llvm_unreachable("unknown object format type");
}
static Triple::ObjectFormatType getDefaultFormat(const Triple &T) {
Teach getDefaultFormat that we only support ELF on some architectures. This should bring the windows bots back. It is a bit ugly, but it is better than what we had before: The triple would say that the object format was COFF, but llc/llvm-mc would produce an ELF. llvm-svn: 232683
2015-03-19 06:19:16 +08:00
switch (T.getArch()) {
default:
break;
case Triple::hexagon:
case Triple::mips:
case Triple::mipsel:
case Triple::mips64:
case Triple::mips64el:
case Triple::r600:
case Triple::amdgcn:
case Triple::sparc:
case Triple::sparcv9:
case Triple::systemz:
case Triple::xcore:
Note that we don't support COFF on PPC. Should bring back the windows bots. llvm-svn: 232701
2015-03-19 10:40:56 +08:00
case Triple::ppc64le:
return Triple::ELF;
case Triple::ppc:
case Triple::ppc64:
if (T.isOSDarwin())
return Triple::MachO;
Teach getDefaultFormat that we only support ELF on some architectures. This should bring the windows bots back. It is a bit ugly, but it is better than what we had before: The triple would say that the object format was COFF, but llc/llvm-mc would produce an ELF. llvm-svn: 232683
2015-03-19 06:19:16 +08:00
return Triple::ELF;
}
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
if (T.isOSDarwin())
return Triple::MachO;
else if (T.isOSWindows())
return Triple::COFF;
return Triple::ELF;
}
Move constructors out-of-line and flesh out their documentation. No functionality changed. This is in preparation for some refactoring of how this class behaves. llvm-svn: 150941
2012-02-20 08:02:47 +08:00
/// \brief Construct a triple from the string representation provided.
///
Clean up comments that I missed when changing the triple representation. Somehow, I even missed the ones I wrote just the other day... Thanks to Matt for the code review. llvm-svn: 151045
2012-02-21 16:31:18 +08:00
/// This stores the string representation and parses the various pieces into
/// enum members.
Switch the llvm::Triple class to immediately parse the triple string on construction. Simplify its interface, implementation, and users accordingly as there is no longer an 'uninitialized' state to check for. Also, fixes a bug lurking in the interface as there was one method that didn't correctly check for initialization. llvm-svn: 151024
2012-02-21 11:39:36 +08:00
Triple::Triple(const Twine &Str)
: Data(Str.str()),
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Arch(parseArch(getArchName())),
Refactor ARM subarchitecture parsing Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
2014-07-18 20:00:48 +08:00
SubArch(parseSubArch(getArchName())),
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Vendor(parseVendor(getVendorName())),
OS(parseOS(getOSName())),
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
Environment(parseEnvironment(getEnvironmentName())),
ObjectFormat(parseFormat(getEnvironmentName())) {
if (ObjectFormat == Triple::UnknownObjectFormat)
ObjectFormat = getDefaultFormat(*this);
Switch the llvm::Triple class to immediately parse the triple string on construction. Simplify its interface, implementation, and users accordingly as there is no longer an 'uninitialized' state to check for. Also, fixes a bug lurking in the interface as there was one method that didn't correctly check for initialization. llvm-svn: 151024
2012-02-21 11:39:36 +08:00
}
Move constructors out-of-line and flesh out their documentation. No functionality changed. This is in preparation for some refactoring of how this class behaves. llvm-svn: 150941
2012-02-20 08:02:47 +08:00
/// \brief Construct a triple from string representations of the architecture,
/// vendor, and OS.
///
Clean up comments that I missed when changing the triple representation. Somehow, I even missed the ones I wrote just the other day... Thanks to Matt for the code review. llvm-svn: 151045
2012-02-21 16:31:18 +08:00
/// This joins each argument into a canonical string representation and parses
/// them into enum members. It leaves the environment unknown and omits it from
/// the string representation.
Move constructors out-of-line and flesh out their documentation. No functionality changed. This is in preparation for some refactoring of how this class behaves. llvm-svn: 150941
2012-02-20 08:02:47 +08:00
Triple::Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr)
: Data((ArchStr + Twine('-') + VendorStr + Twine('-') + OSStr).str()),
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Arch(parseArch(ArchStr.str())),
Refactor ARM subarchitecture parsing Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
2014-07-18 20:00:48 +08:00
SubArch(parseSubArch(ArchStr.str())),
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Vendor(parseVendor(VendorStr.str())),
OS(parseOS(OSStr.str())),
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
Environment(), ObjectFormat(Triple::UnknownObjectFormat) {
ObjectFormat = getDefaultFormat(*this);
Move constructors out-of-line and flesh out their documentation. No functionality changed. This is in preparation for some refactoring of how this class behaves. llvm-svn: 150941
2012-02-20 08:02:47 +08:00
}
/// \brief Construct a triple from string representations of the architecture,
/// vendor, OS, and environment.
///
Clean up comments that I missed when changing the triple representation. Somehow, I even missed the ones I wrote just the other day... Thanks to Matt for the code review. llvm-svn: 151045
2012-02-21 16:31:18 +08:00
/// This joins each argument into a canonical string representation and parses
/// them into enum members.
Move constructors out-of-line and flesh out their documentation. No functionality changed. This is in preparation for some refactoring of how this class behaves. llvm-svn: 150941
2012-02-20 08:02:47 +08:00
Triple::Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr,
const Twine &EnvironmentStr)
: Data((ArchStr + Twine('-') + VendorStr + Twine('-') + OSStr + Twine('-') +
EnvironmentStr).str()),
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Arch(parseArch(ArchStr.str())),
Refactor ARM subarchitecture parsing Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
2014-07-18 20:00:48 +08:00
SubArch(parseSubArch(ArchStr.str())),
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Vendor(parseVendor(VendorStr.str())),
OS(parseOS(OSStr.str())),
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
Environment(parseEnvironment(EnvironmentStr.str())),
ObjectFormat(parseFormat(EnvironmentStr.str())) {
if (ObjectFormat == Triple::UnknownObjectFormat)
ObjectFormat = getDefaultFormat(*this);
Move constructors out-of-line and flesh out their documentation. No functionality changed. This is in preparation for some refactoring of how this class behaves. llvm-svn: 150941
2012-02-20 08:02: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
std::string Triple::normalize(StringRef Str) {
ADT: remove MinGW32 and Cygwin OSType enum Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
2014-08-10 07:12:20 +08:00
bool IsMinGW32 = false;
bool IsCygwin = false;
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
// Parse into components.
SmallVector<StringRef, 4> Components;
Replace a hand rolled loop with a lovely StringRef helper we have these days. No functionality changed. llvm-svn: 151048
2012-02-21 17:12:48 +08:00
Str.split(Components, "-");
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
// If the first component corresponds to a known architecture, preferentially
// use it for the architecture. If the second component corresponds to a
// known vendor, preferentially use it for the vendor, etc. This avoids silly
// component movement when a component parses as (eg) both a valid arch and a
// valid os.
ArchType Arch = UnknownArch;
if (Components.size() > 0)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Arch = parseArch(Components[0]);
Add a 'normalize' method to the Triple class, which takes a mucked up target triple and straightens it out. This does less than gcc's script config.sub, for example it turns i386-mingw32 into i386--mingw32 not i386-pc-mingw32, but it does a decent job of turning funky triples into something that the rest of the Triple class can understand. The plan is to use this to canonicalize triple's when they are first provided by users, and have the rest of LLVM only deal with canonical triples. Once this is done the special case workarounds in the Triple constructor can be removed, making the class more regular and easier to use. The comments and unittests for the Triple class are already adjusted in this patch appropriately for this brave new world of increased uniformity. llvm-svn: 110909
2010-08-12 19:31:39 +08:00
VendorType Vendor = UnknownVendor;
if (Components.size() > 1)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Vendor = parseVendor(Components[1]);
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
OSType OS = UnknownOS;
ADT: remove MinGW32 and Cygwin OSType enum Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
2014-08-10 07:12:20 +08:00
if (Components.size() > 2) {
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
OS = parseOS(Components[2]);
ADT: remove MinGW32 and Cygwin OSType enum Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
2014-08-10 07:12:20 +08:00
IsCygwin = Components[2].startswith("cygwin");
IsMinGW32 = Components[2].startswith("mingw");
}
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
EnvironmentType Environment = UnknownEnvironment;
if (Components.size() > 3)
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Environment = parseEnvironment(Components[3]);
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
ObjectFormatType ObjectFormat = UnknownObjectFormat;
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
if (Components.size() > 4)
ObjectFormat = parseFormat(Components[4]);
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
// Note which components are already in their final position. These will not
// be moved.
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
bool Found[4];
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
Found[0] = Arch != UnknownArch;
Found[1] = Vendor != UnknownVendor;
Found[2] = OS != UnknownOS;
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
Found[3] = Environment != UnknownEnvironment;
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
// If they are not there already, permute the components into their canonical
// positions by seeing if they parse as a valid architecture, and if so moving
// the component to the architecture position etc.
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
for (unsigned Pos = 0; Pos != array_lengthof(Found); ++Pos) {
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
if (Found[Pos])
continue; // Already in the canonical position.
for (unsigned Idx = 0; Idx != Components.size(); ++Idx) {
// Do not reparse any components that already matched.
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
if (Idx < array_lengthof(Found) && Found[Idx])
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
continue;
// Does this component parse as valid for the target position?
bool Valid = false;
StringRef Comp = Components[Idx];
switch (Pos) {
Convert assert(0) to llvm_unreachable llvm-svn: 149967
2012-02-07 13:05:23 +08:00
default: llvm_unreachable("unexpected component type!");
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
case 0:
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Arch = parseArch(Comp);
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
Valid = Arch != UnknownArch;
break;
case 1:
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Vendor = parseVendor(Comp);
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
Valid = Vendor != UnknownVendor;
break;
case 2:
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
OS = parseOS(Comp);
ADT: remove MinGW32 and Cygwin OSType enum Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
2014-08-10 07:12:20 +08:00
IsCygwin = Comp.startswith("cygwin");
IsMinGW32 = Comp.startswith("mingw");
Valid = OS != UnknownOS || IsCygwin || IsMinGW32;
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
break;
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
case 3:
Pull the parsing helper functions out of the Triple interface entirely. They're private static methods but we can just make them static functions in the implementation. It makes the implementations a touch more wordy, but takes another chunk out of the header file. Also, take the opportunity to switch the names to the new coding conventions. No functionality changed here. llvm-svn: 151047
2012-02-21 16:53:32 +08:00
Environment = parseEnvironment(Comp);
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
Valid = Environment != UnknownEnvironment;
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
if (!Valid) {
ObjectFormat = parseFormat(Comp);
Valid = ObjectFormat != UnknownObjectFormat;
}
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
break;
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
}
if (!Valid)
continue; // Nope, try the next component.
// Move the component to the target position, pushing any non-fixed
// components that are in the way to the right. This tends to give
// good results in the common cases of a forgotten vendor component
// or a wrongly positioned environment.
if (Pos < Idx) {
// Insert left, pushing the existing components to the right. For
// example, a-b-i386 -> i386-a-b when moving i386 to the front.
StringRef CurrentComponent(""); // The empty component.
// Replace the component we are moving with an empty component.
std::swap(CurrentComponent, Components[Idx]);
// Insert the component being moved at Pos, displacing any existing
// components to the right.
for (unsigned i = Pos; !CurrentComponent.empty(); ++i) {
// Skip over any fixed components.
Tiny cosmetic change to use the same style for all of the while loops in the normalize routine, especially the empty while loops. llvm-svn: 151050
2012-02-21 17:29:14 +08:00
while (i < array_lengthof(Found) && Found[i])
++i;
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
// Place the component at the new position, getting the component
// that was at this position - it will be moved right.
std::swap(CurrentComponent, Components[i]);
}
} else if (Pos > Idx) {
// Push right by inserting empty components until the component at Idx
// reaches the target position Pos. For example, pc-a -> -pc-a when
// moving pc to the second position.
do {
// Insert one empty component at Idx.
StringRef CurrentComponent(""); // The empty component.
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
for (unsigned i = Idx; i < Components.size();) {
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
// Place the component at the new position, getting the component
// that was at this position - it will be moved right.
std::swap(CurrentComponent, Components[i]);
// If it was placed on top of an empty component then we are done.
if (CurrentComponent.empty())
break;
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
// Advance to the next component, skipping any fixed components.
Fix a clang warning. llvm-svn: 124960
2011-02-06 02:19:35 +08:00
while (++i < array_lengthof(Found) && Found[i])
;
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
}
// The last component was pushed off the end - append it.
if (!CurrentComponent.empty())
Components.push_back(CurrentComponent);
// Advance Idx to the component's new position.
Tiny cosmetic change to use the same style for all of the while loops in the normalize routine, especially the empty while loops. llvm-svn: 151050
2012-02-21 17:29:14 +08:00
while (++Idx < array_lengthof(Found) && Found[Idx])
;
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
} while (Idx < Pos); // Add more until the final position is reached.
}
assert(Pos < Components.size() && Components[Pos] == Comp &&
"Component moved wrong!");
Found[Pos] = true;
break;
}
}
// Special case logic goes here. At this point Arch, Vendor and OS have the
// correct values for the computed components.
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
if (OS == Triple::Win32) {
Components.resize(4);
Components[2] = "windows";
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
if (Environment == UnknownEnvironment) {
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
if (ObjectFormat == UnknownObjectFormat || ObjectFormat == Triple::COFF)
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
Components[3] = "msvc";
else
Components[3] = getObjectFormatTypeName(ObjectFormat);
}
ADT: remove MinGW32 and Cygwin OSType enum Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
2014-08-10 07:12:20 +08:00
} else if (IsMinGW32) {
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
Components.resize(4);
Components[2] = "windows";
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
Components[3] = "gnu";
ADT: remove MinGW32 and Cygwin OSType enum Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
2014-08-10 07:12:20 +08:00
} else if (IsCygwin) {
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
Components.resize(4);
Components[2] = "windows";
Components[3] = "cygnus";
}
ADT: remove MinGW32 and Cygwin OSType enum Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
2014-08-10 07:12:20 +08:00
if (IsMinGW32 || IsCygwin ||
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
(OS == Triple::Win32 && Environment != UnknownEnvironment)) {
if (ObjectFormat != UnknownObjectFormat && ObjectFormat != Triple::COFF) {
Components.resize(5);
Components[4] = getObjectFormatTypeName(ObjectFormat);
}
}
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
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
// Stick the corrected components back together to form the normalized string.
std::string Normalized;
for (unsigned i = 0, e = Components.size(); i != e; ++i) {
if (i) Normalized += '-';
Normalized += Components[i];
}
return Normalized;
}
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
StringRef Triple::getArchName() const {
return StringRef(Data).split('-').first; // Isolate first component
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
}
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
StringRef Triple::getVendorName() const {
StringRef Tmp = StringRef(Data).split('-').second; // Strip first component
return Tmp.split('-').first; // Isolate second component
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
}
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
StringRef Triple::getOSName() const {
StringRef Tmp = StringRef(Data).split('-').second; // Strip first component
Tmp = Tmp.split('-').second; // Strip second component
return Tmp.split('-').first; // Isolate third component
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
}
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
StringRef Triple::getEnvironmentName() const {
StringRef Tmp = StringRef(Data).split('-').second; // Strip first component
Tmp = Tmp.split('-').second; // Strip second component
return Tmp.split('-').second; // Strip third component
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
}
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
StringRef Triple::getOSAndEnvironmentName() const {
StringRef Tmp = StringRef(Data).split('-').second; // Strip first component
return Tmp.split('-').second; // Strip second component
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 couple of helpers to the Triple class for decoding the darwin version string. This should help consolidate the variety of weird functions we have scattered around the codebase that do stuff like this. llvm-svn: 78792
2009-08-12 14:19:40 +08:00
static unsigned EatNumber(StringRef &Str) {
assert(!Str.empty() && Str[0] >= '0' && Str[0] <= '9' && "Not a number");
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
unsigned Result = 0;
Trailing whitespace and 80 column fixups. llvm-svn: 122026
2010-12-17 10:10:59 +08:00
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
do {
// Consume the leading digit.
add a couple of helpers to the Triple class for decoding the darwin version string. This should help consolidate the variety of weird functions we have scattered around the codebase that do stuff like this. llvm-svn: 78792
2009-08-12 14:19:40 +08:00
Result = Result*10 + (Str[0] - '0');
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
add a couple of helpers to the Triple class for decoding the darwin version string. This should help consolidate the variety of weird functions we have scattered around the codebase that do stuff like this. llvm-svn: 78792
2009-08-12 14:19:40 +08:00
// Eat the digit.
Str = Str.substr(1);
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
} while (!Str.empty() && Str[0] >= '0' && Str[0] <= '9');
Trailing whitespace and 80 column fixups. llvm-svn: 122026
2010-12-17 10:10:59 +08:00
add a couple of helpers to the Triple class for decoding the darwin version string. This should help consolidate the variety of weird functions we have scattered around the codebase that do stuff like this. llvm-svn: 78792
2009-08-12 14:19:40 +08:00
return Result;
}
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
void Triple::getOSVersion(unsigned &Major, unsigned &Minor,
unsigned &Micro) const {
add a couple of helpers to the Triple class for decoding the darwin version string. This should help consolidate the variety of weird functions we have scattered around the codebase that do stuff like this. llvm-svn: 78792
2009-08-12 14:19:40 +08:00
StringRef OSName = getOSName();
Make Triple::getOSVersion make sense for Android. Reviewers: srhines Reviewed By: srhines Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7928 llvm-svn: 231090
2015-03-04 02:23:51 +08:00
// For Android, we care about the Android version rather than the Linux
// version.
if (getEnvironment() == Android) {
OSName = getEnvironmentName().substr(strlen("android"));
if (OSName.startswith("eabi"))
OSName = OSName.substr(strlen("eabi"));
}
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
// Assume that the OS portion of the triple starts with the canonical name.
StringRef OSTypeName = getOSTypeName(getOS());
if (OSName.startswith(OSTypeName))
OSName = OSName.substr(OSTypeName.size());
Trailing whitespace and 80 column fixups. llvm-svn: 122026
2010-12-17 10:10:59 +08:00
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
// Any unset version defaults to 0.
Major = Minor = Micro = 0;
Trailing whitespace and 80 column fixups. llvm-svn: 122026
2010-12-17 10:10:59 +08:00
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
// Parse up to three components.
unsigned *Components[3] = { &Major, &Minor, &Micro };
for (unsigned i = 0; i != 3; ++i) {
if (OSName.empty() || OSName[0] < '0' || OSName[0] > '9')
break;
Trailing whitespace and 80 column fixups. llvm-svn: 122026
2010-12-17 10:10:59 +08:00
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
// Consume the leading number.
*Components[i] = EatNumber(OSName);
add a couple of helpers to the Triple class for decoding the darwin version string. This should help consolidate the variety of weird functions we have scattered around the codebase that do stuff like this. llvm-svn: 78792
2009-08-12 14:19:40 +08:00
ADT/Triple: Generalize and simplify getDarwinNumber to just be getOSVersion. llvm-svn: 129799
2011-04-20 04:24:34 +08:00
// Consume the separator, if present.
if (OSName.startswith("."))
OSName = OSName.substr(1);
}
add a couple of helpers to the Triple class for decoding the darwin version string. This should help consolidate the variety of weird functions we have scattered around the codebase that do stuff like this. llvm-svn: 78792
2009-08-12 14:19:40 +08:00
}
Add Triple::getMacOSXVersion to replace crufty code in the clang driver. This new function provides a way to get the Mac OS X version number from either generic "darwin" triples of macosx triples. llvm-svn: 149438
2012-02-01 06:32:29 +08:00
bool Triple::getMacOSXVersion(unsigned &Major, unsigned &Minor,
unsigned &Micro) const {
getOSVersion(Major, Minor, Micro);
switch (getOS()) {
Convert assert(0) to llvm_unreachable llvm-svn: 149967
2012-02-07 13:05:23 +08:00
default: llvm_unreachable("unexpected OS for Darwin triple");
Add Triple::getMacOSXVersion to replace crufty code in the clang driver. This new function provides a way to get the Mac OS X version number from either generic "darwin" triples of macosx triples. llvm-svn: 149438
2012-02-01 06:32:29 +08:00
case Darwin:
// Default to darwin8, i.e., MacOSX 10.4.
if (Major == 0)
Major = 8;
// Darwin version numbers are skewed from OS X versions.
if (Major < 4)
return false;
Micro = 0;
Minor = Major - 4;
Major = 10;
break;
case MacOSX:
// Default to 10.4.
if (Major == 0) {
Major = 10;
Minor = 4;
}
if (Major != 10)
return false;
break;
case IOS:
// Ignore the version from the triple. This is only handled because the
// the clang driver combines OS X and IOS support into a common Darwin
// toolchain that wants to know the OS X version number even when targeting
// IOS.
Major = 10;
Minor = 4;
Micro = 0;
break;
}
return true;
}
Add Triple::getiOSVersion. This new function provides a way to get the iOS version number from ios triples. Part of rdar://11409204 llvm-svn: 156483
2012-05-10 01:23:48 +08:00
void Triple::getiOSVersion(unsigned &Major, unsigned &Minor,
unsigned &Micro) const {
switch (getOS()) {
default: llvm_unreachable("unexpected OS for Darwin triple");
case Darwin:
case MacOSX:
// Ignore the version from the triple. This is only handled because the
// the clang driver combines OS X and IOS support into a common Darwin
// toolchain that wants to know the iOS version number even when targeting
// OS X.
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
Major = 5;
Add Triple::getiOSVersion. This new function provides a way to get the iOS version number from ios triples. Part of rdar://11409204 llvm-svn: 156483
2012-05-10 01:23:48 +08:00
Minor = 0;
Micro = 0;
Don't return true on a function with a void return type. llvm-svn: 156484
2012-05-10 01:38:47 +08:00
break;
Add Triple::getiOSVersion. This new function provides a way to get the iOS version number from ios triples. Part of rdar://11409204 llvm-svn: 156483
2012-05-10 01:23:48 +08:00
case IOS:
getOSVersion(Major, Minor, Micro);
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 18:18:08 +08:00
// Default to 5.0 (or 7.0 for arm64).
Set the default iOS version to 3.0. llvm-svn: 156492
2012-05-10 02:23:00 +08:00
if (Major == 0)
AArch64: remove arm64 triple enumerator. Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and invites bugs where only one is checked. In reality, the only legitimate difference between the two (arm64 usually means iOS) is also present in the OS part of the triple and that's what should be checked. We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so there aren't any LLVM-side test changes. llvm-svn: 213743
2014-07-23 20:32:47 +08:00
Major = (getArch() == aarch64) ? 7 : 5;
Add Triple::getiOSVersion. This new function provides a way to get the iOS version number from ios triples. Part of rdar://11409204 llvm-svn: 156483
2012-05-10 01:23:48 +08:00
break;
}
}
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
void Triple::setTriple(const Twine &Str) {
Switch the llvm::Triple class to immediately parse the triple string on construction. Simplify its interface, implementation, and users accordingly as there is no longer an 'uninitialized' state to check for. Also, fixes a bug lurking in the interface as there was one method that didn't correctly check for initialization. llvm-svn: 151024
2012-02-21 11:39:36 +08:00
*this = Triple(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
}
void Triple::setArch(ArchType Kind) {
setArchName(getArchTypeName(Kind));
}
void Triple::setVendor(VendorType Kind) {
setVendorName(getVendorTypeName(Kind));
}
void Triple::setOS(OSType Kind) {
setOSName(getOSTypeName(Kind));
}
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
void Triple::setEnvironment(EnvironmentType Kind) {
Triple: Make setEnvironment not override the object format Discovered by Halide users who had C++ code like this: Triple.setArch(Triple::x86); Triple.setOS(Triple::Windows); Triple.setObjectFormat(Triple::ELF); Triple.setEnvironment(Triple::MSVC); This would produce the stringified triple of x86-windows-msvc, instead of the x86-windows-msvc-elf string needed to run MCJIT. With this change, they retain the -elf suffix. llvm-svn: 229160
2015-02-14 06:05:50 +08:00
if (ObjectFormat == getDefaultFormat(*this))
return setEnvironmentName(getEnvironmentTypeName(Kind));
setEnvironmentName((getEnvironmentTypeName(Kind) + Twine("-") +
getObjectFormatTypeName(ObjectFormat)).str());
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
}
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
void Triple::setObjectFormat(ObjectFormatType Kind) {
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
if (Environment == UnknownEnvironment)
return setEnvironmentName(getObjectFormatTypeName(Kind));
Fix some Twine locals. Two of those are use after frees. Found by clang-tidy, fixed by me. llvm-svn: 212537
2014-07-08 22:55:06 +08:00
setEnvironmentName((getEnvironmentTypeName(Environment) + Twine("-") +
getObjectFormatTypeName(Kind)).str());
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
}
Pass StringRef by value. llvm-svn: 86251
2009-11-06 18:58:06 +08:00
void Triple::setArchName(StringRef Str) {
r83391 was completely broken since Twines keep references to their inputs, and some of the inputs were temporaries. Here's a real fix for the miscompilation. Thanks to sabre for pointing out the problem. llvm-svn: 83417
2009-10-07 05:45:26 +08:00
// Work around a miscompilation bug for Twines in gcc 4.0.3.
SmallString<64> Triple;
Triple += Str;
Triple += "-";
Triple += getVendorName();
Triple += "-";
Triple += getOSAndEnvironmentName();
Remove many superfluous SmallString::str() calls. Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
2015-03-18 18:17:07 +08:00
setTriple(Triple);
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
}
Pass StringRef by value. llvm-svn: 86251
2009-11-06 18:58:06 +08:00
void Triple::setVendorName(StringRef 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
setTriple(getArchName() + "-" + Str + "-" + getOSAndEnvironmentName());
}
Pass StringRef by value. llvm-svn: 86251
2009-11-06 18:58:06 +08:00
void Triple::setOSName(StringRef 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
if (hasEnvironment())
setTriple(getArchName() + "-" + getVendorName() + "-" + Str +
"-" + getEnvironmentName());
else
setTriple(getArchName() + "-" + getVendorName() + "-" + Str);
}
Pass StringRef by value. llvm-svn: 86251
2009-11-06 18:58:06 +08:00
void Triple::setEnvironmentName(StringRef Str) {
setTriple(getArchName() + "-" + getVendorName() + "-" + getOSName() +
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
"-" + Str);
}
Pass StringRef by value. llvm-svn: 86251
2009-11-06 18:58:06 +08:00
void Triple::setOSAndEnvironmentName(StringRef 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
setTriple(getArchName() + "-" + getVendorName() + "-" + Str);
}
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
static unsigned getArchPointerBitWidth(llvm::Triple::ArchType Arch) {
switch (Arch) {
case llvm::Triple::UnknownArch:
return 0;
case llvm::Triple::msp430:
return 16;
case llvm::Triple::arm:
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case llvm::Triple::armeb:
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
case llvm::Triple::hexagon:
case llvm::Triple::le32:
case llvm::Triple::mips:
case llvm::Triple::mipsel:
This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it. The new target machines are: nvptx (old ptx32) => 32-bit PTX nvptx64 (old ptx64) => 64-bit PTX The sources are based on the internal NVIDIA NVPTX back-end, and contain more functionality than the current PTX back-end currently provides. NV_CONTRIB llvm-svn: 156196
2012-05-05 04:18:50 +08:00
case llvm::Triple::nvptx:
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
case llvm::Triple::ppc:
Add support for r600 (AMD GPUs HD2XXX - HD6XXX) target triplet. Patch by Tom Stellard! llvm-svn: 152400
2012-03-09 18:09:36 +08:00
case llvm::Triple::r600:
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
case llvm::Triple::sparc:
case llvm::Triple::tce:
case llvm::Triple::thumb:
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case llvm::Triple::thumbeb:
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
case llvm::Triple::x86:
case llvm::Triple::xcore:
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case llvm::Triple::amdil:
case llvm::Triple::hsail:
Add support for SPIR64 target - the 64bit counterpart of SPIR. The new OpenCL SPIR extension spec will define separate SPIR for 32 and 64 bit architectures. llvm-svn: 168036
2012-11-15 18:35:47 +08:00
case llvm::Triple::spir:
Add the CSR company and the Kalimba DSP processor to Triple. Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
2014-07-11 01:26:54 +08:00
case llvm::Triple::kalimba:
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
return 32;
Add AArch64 as an experimental target. This patch adds support for AArch64 (ARM's 64-bit architecture) to LLVM in the "experimental" category. Currently, it won't be built unless requested explicitly. This initial commit should have support for: + Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions (except the late addition CRC instructions). + CodeGen features required for C++03 and C99. + Compilation for the "small" memory model: code+static data < 4GB. + Absolute and position-independent code. + GNU-style (i.e. "__thread") TLS. + Debugging information. The principal omission, currently, is performance tuning. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174054
2013-01-31 20:12:40 +08:00
case llvm::Triple::aarch64:
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case llvm::Triple::aarch64_be:
Triple: Add amdgcn triple This will be used for AMD GPUs with the Graphics Core Next architecture, which are currently using by the r600 triple. llvm-svn: 225276
2015-01-07 02:00:00 +08:00
case llvm::Triple::amdgcn:
BPF backend Summary: V8->V9: - cleanup tests V7->V8: - addressed feedback from David: - switched to range-based 'for' loops - fixed formatting of tests V6->V7: - rebased and adjusted AsmPrinter args - CamelCased .td, fixed formatting, cleaned up names, removed unused patterns - diffstat: 3 files changed, 203 insertions(+), 227 deletions(-) V5->V6: - addressed feedback from Chandler: - reinstated full verbose standard banner in all files - fixed variables that were not in CamelCase - fixed names of #ifdef in header files - removed redundant braces in if/else chains with single statements - fixed comments - removed trailing empty line - dropped debug annotations from tests - diffstat of these changes: 46 files changed, 456 insertions(+), 469 deletions(-) V4->V5: - fix setLoadExtAction() interface - clang-formated all where it made sense V3->V4: - added CODE_OWNERS entry for BPF backend V2->V3: - fix metadata in tests V1->V2: - addressed feedback from Tom and Matt - removed top level change to configure (now everything via 'experimental-backend') - reworked error reporting via DiagnosticInfo (similar to R600) - added few more tests - added cmake build - added Triple::bpf - tested on linux and darwin V1 cover letter: --------------------- recently linux gained "universal in-kernel virtual machine" which is called eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since new instruction set is based on it. This patch adds a new backend that emits extended BPF instruction set. The concept and development are covered by the following articles: http://lwn.net/Articles/599755/ http://lwn.net/Articles/575531/ http://lwn.net/Articles/603983/ http://lwn.net/Articles/606089/ http://lwn.net/Articles/612878/ One of use cases: dtrace/systemtap alternative. bpf syscall manpage: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe instruction set description and differences vs classic BPF: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt Short summary of instruction set: - 64-bit registers R0 - return value from in-kernel function, and exit value for BPF program R1 - R5 - arguments from BPF program to in-kernel function R6 - R9 - callee saved registers that in-kernel function will preserve R10 - read-only frame pointer to access stack - two-operand instructions like +, -, *, mov, load/store - implicit prologue/epilogue (invisible stack pointer) - no floating point, no simd Short history of extended BPF in kernel: interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future. It's a very small and simple backend. There is no support for global variables, arbitrary function calls, floating point, varargs, exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc. From C front-end point of view it's very restricted. It's done on purpose, since kernel rejects all programs that it cannot prove safe. It rejects programs with loops and with memory accesses via arbitrary pointers. When kernel accepts the program it is guaranteed that program will terminate and will not crash the kernel. This patch implements all 'must have' bits. There are several things on TODO list, so this is not the end of development. Most of the code is a boiler plate code, copy-pasted from other backends. Only odd things are lack or < and <= instructions, specialized load_byte intrinsics and 'compare and goto' as single instruction. Current instruction set is fixed, but more instructions can be added in the future. Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D6494 llvm-svn: 227008
2015-01-25 01:51:26 +08:00
case llvm::Triple::bpf:
Add support for le64. Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Depends on D5318. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5319 llvm-svn: 217697
2014-09-13 01:54:17 +08:00
case llvm::Triple::le64:
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
case llvm::Triple::mips64:
case llvm::Triple::mips64el:
This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it. The new target machines are: nvptx (old ptx32) => 32-bit PTX nvptx64 (old ptx64) => 64-bit PTX The sources are based on the internal NVIDIA NVPTX back-end, and contain more functionality than the current PTX back-end currently provides. NV_CONTRIB llvm-svn: 156196
2012-05-05 04:18:50 +08:00
case llvm::Triple::nvptx64:
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
case llvm::Triple::ppc64:
[PowerPC] Support powerpc64le as a syntax-checking target. This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
2013-07-26 09:35:43 +08:00
case llvm::Triple::ppc64le:
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
case llvm::Triple::sparcv9:
[SystemZ] Add llvm::Triple::systemz First step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. llvm-svn: 181007
2013-05-03 19:05:17 +08:00
case llvm::Triple::systemz:
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
case llvm::Triple::x86_64:
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case llvm::Triple::amdil64:
case llvm::Triple::hsail64:
Add support for SPIR64 target - the 64bit counterpart of SPIR. The new OpenCL SPIR extension spec will define separate SPIR for 32 and 64 bit architectures. llvm-svn: 168036
2012-11-15 18:35:47 +08:00
case llvm::Triple::spir64:
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
return 64;
}
llvm_unreachable("Invalid architecture value");
}
bool Triple::isArch64Bit() const {
return getArchPointerBitWidth(getArch()) == 64;
}
bool Triple::isArch32Bit() const {
return getArchPointerBitWidth(getArch()) == 32;
}
bool Triple::isArch16Bit() const {
return getArchPointerBitWidth(getArch()) == 16;
}
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 Triple::get32BitArchVariant() const {
Triple T(*this);
switch (getArch()) {
case Triple::UnknownArch:
Add AArch64 as an experimental target. This patch adds support for AArch64 (ARM's 64-bit architecture) to LLVM in the "experimental" category. Currently, it won't be built unless requested explicitly. This initial commit should have support for: + Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions (except the late addition CRC instructions). + CodeGen features required for C++03 and C99. + Compilation for the "small" memory model: code+static data < 4GB. + Absolute and position-independent code. + GNU-style (i.e. "__thread") TLS. + Debugging information. The principal omission, currently, is performance tuning. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174054
2013-01-31 20:12:40 +08:00
case Triple::aarch64:
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case Triple::aarch64_be:
Triple: Add amdgcn triple This will be used for AMD GPUs with the Graphics Core Next architecture, which are currently using by the r600 triple. llvm-svn: 225276
2015-01-07 02:00:00 +08:00
case Triple::amdgcn:
BPF backend Summary: V8->V9: - cleanup tests V7->V8: - addressed feedback from David: - switched to range-based 'for' loops - fixed formatting of tests V6->V7: - rebased and adjusted AsmPrinter args - CamelCased .td, fixed formatting, cleaned up names, removed unused patterns - diffstat: 3 files changed, 203 insertions(+), 227 deletions(-) V5->V6: - addressed feedback from Chandler: - reinstated full verbose standard banner in all files - fixed variables that were not in CamelCase - fixed names of #ifdef in header files - removed redundant braces in if/else chains with single statements - fixed comments - removed trailing empty line - dropped debug annotations from tests - diffstat of these changes: 46 files changed, 456 insertions(+), 469 deletions(-) V4->V5: - fix setLoadExtAction() interface - clang-formated all where it made sense V3->V4: - added CODE_OWNERS entry for BPF backend V2->V3: - fix metadata in tests V1->V2: - addressed feedback from Tom and Matt - removed top level change to configure (now everything via 'experimental-backend') - reworked error reporting via DiagnosticInfo (similar to R600) - added few more tests - added cmake build - added Triple::bpf - tested on linux and darwin V1 cover letter: --------------------- recently linux gained "universal in-kernel virtual machine" which is called eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since new instruction set is based on it. This patch adds a new backend that emits extended BPF instruction set. The concept and development are covered by the following articles: http://lwn.net/Articles/599755/ http://lwn.net/Articles/575531/ http://lwn.net/Articles/603983/ http://lwn.net/Articles/606089/ http://lwn.net/Articles/612878/ One of use cases: dtrace/systemtap alternative. bpf syscall manpage: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe instruction set description and differences vs classic BPF: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt Short summary of instruction set: - 64-bit registers R0 - return value from in-kernel function, and exit value for BPF program R1 - R5 - arguments from BPF program to in-kernel function R6 - R9 - callee saved registers that in-kernel function will preserve R10 - read-only frame pointer to access stack - two-operand instructions like +, -, *, mov, load/store - implicit prologue/epilogue (invisible stack pointer) - no floating point, no simd Short history of extended BPF in kernel: interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future. It's a very small and simple backend. There is no support for global variables, arbitrary function calls, floating point, varargs, exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc. From C front-end point of view it's very restricted. It's done on purpose, since kernel rejects all programs that it cannot prove safe. It rejects programs with loops and with memory accesses via arbitrary pointers. When kernel accepts the program it is guaranteed that program will terminate and will not crash the kernel. This patch implements all 'must have' bits. There are several things on TODO list, so this is not the end of development. Most of the code is a boiler plate code, copy-pasted from other backends. Only odd things are lack or < and <= instructions, specialized load_byte intrinsics and 'compare and goto' as single instruction. Current instruction set is fixed, but more instructions can be added in the future. Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D6494 llvm-svn: 227008
2015-01-25 01:51:26 +08:00
case Triple::bpf:
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
case Triple::msp430:
[SystemZ] Add llvm::Triple::systemz First step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. llvm-svn: 181007
2013-05-03 19:05:17 +08:00
case Triple::systemz:
[PowerPC] Support powerpc64le as a syntax-checking target. This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
2013-07-26 09:35:43 +08:00
case Triple::ppc64le:
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(UnknownArch);
break;
case Triple::amdil:
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case Triple::hsail:
Add in support for SPIR to LLVM core. This adds a new target and two new calling conventions. llvm-svn: 164948
2012-10-02 01:01:31 +08:00
case Triple::spir:
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
case Triple::arm:
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case Triple::armeb:
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
case Triple::hexagon:
Add the CSR company and the Kalimba DSP processor to Triple. Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
2014-07-11 01:26:54 +08:00
case Triple::kalimba:
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
case Triple::le32:
case Triple::mips:
case Triple::mipsel:
This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it. The new target machines are: nvptx (old ptx32) => 32-bit PTX nvptx64 (old ptx64) => 64-bit PTX The sources are based on the internal NVIDIA NVPTX back-end, and contain more functionality than the current PTX back-end currently provides. NV_CONTRIB llvm-svn: 156196
2012-05-05 04:18:50 +08:00
case Triple::nvptx:
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
case Triple::ppc:
Add support for r600 (AMD GPUs HD2XXX - HD6XXX) target triplet. Patch by Tom Stellard! llvm-svn: 152400
2012-03-09 18:09:36 +08:00
case Triple::r600:
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
case Triple::sparc:
case Triple::tce:
case Triple::thumb:
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case Triple::thumbeb:
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
case Triple::x86:
case Triple::xcore:
// Already 32-bit.
break;
Add support for le64. Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Depends on D5318. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5319 llvm-svn: 217697
2014-09-13 01:54:17 +08:00
case Triple::le64: T.setArch(Triple::le32); break;
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
case Triple::mips64: T.setArch(Triple::mips); break;
case Triple::mips64el: T.setArch(Triple::mipsel); break;
This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it. The new target machines are: nvptx (old ptx32) => 32-bit PTX nvptx64 (old ptx64) => 64-bit PTX The sources are based on the internal NVIDIA NVPTX back-end, and contain more functionality than the current PTX back-end currently provides. NV_CONTRIB llvm-svn: 156196
2012-05-05 04:18:50 +08:00
case Triple::nvptx64: T.setArch(Triple::nvptx); break;
Fix inconsistent whitespace. llvm-svn: 203423
2014-03-10 07:17:28 +08:00
case Triple::ppc64: T.setArch(Triple::ppc); break;
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
case Triple::sparcv9: T.setArch(Triple::sparc); break;
case Triple::x86_64: T.setArch(Triple::x86); break;
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case Triple::amdil64: T.setArch(Triple::amdil); break;
case Triple::hsail64: T.setArch(Triple::hsail); break;
Add support for SPIR64 target - the 64bit counterpart of SPIR. The new OpenCL SPIR extension spec will define separate SPIR for 32 and 64 bit architectures. llvm-svn: 168036
2012-11-15 18:35:47 +08:00
case Triple::spir64: T.setArch(Triple::spir); break;
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
}
return T;
}
Triple Triple::get64BitArchVariant() const {
Triple T(*this);
switch (getArch()) {
case Triple::UnknownArch:
ARM64: remove -m32/-m64 mapping with ARM. This is causing the ARM build-bots to fail since they only include the ARM backend and can't create an ARM64 target. llvm-svn: 205132
2014-03-30 15:25:23 +08:00
case Triple::arm:
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case Triple::armeb:
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
case Triple::hexagon:
Add the CSR company and the Kalimba DSP processor to Triple. Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
2014-07-11 01:26:54 +08:00
case Triple::kalimba:
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
case Triple::msp430:
Add support for r600 (AMD GPUs HD2XXX - HD6XXX) target triplet. Patch by Tom Stellard! llvm-svn: 152400
2012-03-09 18:09:36 +08:00
case Triple::r600:
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
case Triple::tce:
case Triple::thumb:
Add ARM big endian Target (armeb, thumbeb) Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
2014-03-28 22:35:30 +08:00
case Triple::thumbeb:
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
case Triple::xcore:
T.setArch(UnknownArch);
break;
Add AArch64 as an experimental target. This patch adds support for AArch64 (ARM's 64-bit architecture) to LLVM in the "experimental" category. Currently, it won't be built unless requested explicitly. This initial commit should have support for: + Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions (except the late addition CRC instructions). + CodeGen features required for C++03 and C99. + Compilation for the "small" memory model: code+static data < 4GB. + Absolute and position-independent code. + GNU-style (i.e. "__thread") TLS. + Debugging information. The principal omission, currently, is performance tuning. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174054
2013-01-31 20:12:40 +08:00
case Triple::aarch64:
Add AArch64 big endian Target (aarch64_be) llvm-svn: 202024
2014-02-24 19:34:50 +08:00
case Triple::aarch64_be:
BPF backend Summary: V8->V9: - cleanup tests V7->V8: - addressed feedback from David: - switched to range-based 'for' loops - fixed formatting of tests V6->V7: - rebased and adjusted AsmPrinter args - CamelCased .td, fixed formatting, cleaned up names, removed unused patterns - diffstat: 3 files changed, 203 insertions(+), 227 deletions(-) V5->V6: - addressed feedback from Chandler: - reinstated full verbose standard banner in all files - fixed variables that were not in CamelCase - fixed names of #ifdef in header files - removed redundant braces in if/else chains with single statements - fixed comments - removed trailing empty line - dropped debug annotations from tests - diffstat of these changes: 46 files changed, 456 insertions(+), 469 deletions(-) V4->V5: - fix setLoadExtAction() interface - clang-formated all where it made sense V3->V4: - added CODE_OWNERS entry for BPF backend V2->V3: - fix metadata in tests V1->V2: - addressed feedback from Tom and Matt - removed top level change to configure (now everything via 'experimental-backend') - reworked error reporting via DiagnosticInfo (similar to R600) - added few more tests - added cmake build - added Triple::bpf - tested on linux and darwin V1 cover letter: --------------------- recently linux gained "universal in-kernel virtual machine" which is called eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since new instruction set is based on it. This patch adds a new backend that emits extended BPF instruction set. The concept and development are covered by the following articles: http://lwn.net/Articles/599755/ http://lwn.net/Articles/575531/ http://lwn.net/Articles/603983/ http://lwn.net/Articles/606089/ http://lwn.net/Articles/612878/ One of use cases: dtrace/systemtap alternative. bpf syscall manpage: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe instruction set description and differences vs classic BPF: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt Short summary of instruction set: - 64-bit registers R0 - return value from in-kernel function, and exit value for BPF program R1 - R5 - arguments from BPF program to in-kernel function R6 - R9 - callee saved registers that in-kernel function will preserve R10 - read-only frame pointer to access stack - two-operand instructions like +, -, *, mov, load/store - implicit prologue/epilogue (invisible stack pointer) - no floating point, no simd Short history of extended BPF in kernel: interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future. It's a very small and simple backend. There is no support for global variables, arbitrary function calls, floating point, varargs, exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc. From C front-end point of view it's very restricted. It's done on purpose, since kernel rejects all programs that it cannot prove safe. It rejects programs with loops and with memory accesses via arbitrary pointers. When kernel accepts the program it is guaranteed that program will terminate and will not crash the kernel. This patch implements all 'must have' bits. There are several things on TODO list, so this is not the end of development. Most of the code is a boiler plate code, copy-pasted from other backends. Only odd things are lack or < and <= instructions, specialized load_byte intrinsics and 'compare and goto' as single instruction. Current instruction set is fixed, but more instructions can be added in the future. Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D6494 llvm-svn: 227008
2015-01-25 01:51:26 +08:00
case Triple::bpf:
Add support for le64. Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Depends on D5318. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5319 llvm-svn: 217697
2014-09-13 01:54:17 +08:00
case Triple::le64:
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case Triple::amdil64:
Triple: Add amdgcn triple This will be used for AMD GPUs with the Graphics Core Next architecture, which are currently using by the r600 triple. llvm-svn: 225276
2015-01-07 02:00:00 +08:00
case Triple::amdgcn:
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case Triple::hsail64:
case Triple::spir64:
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
case Triple::mips64:
case Triple::mips64el:
This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it. The new target machines are: nvptx (old ptx32) => 32-bit PTX nvptx64 (old ptx64) => 64-bit PTX The sources are based on the internal NVIDIA NVPTX back-end, and contain more functionality than the current PTX back-end currently provides. NV_CONTRIB llvm-svn: 156196
2012-05-05 04:18:50 +08:00
case Triple::nvptx64:
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
case Triple::ppc64:
[PowerPC] Support powerpc64le as a syntax-checking target. This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
2013-07-26 09:35:43 +08:00
case Triple::ppc64le:
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
case Triple::sparcv9:
[SystemZ] Add llvm::Triple::systemz First step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. llvm-svn: 181007
2013-05-03 19:05:17 +08:00
case Triple::systemz:
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
case Triple::x86_64:
// Already 64-bit.
break;
Add support for le64. Summary: le64 is a generic little-endian 64-bit processor, mimicking le32. Depends on D5318. Test Plan: make check-all Reviewers: dschuff Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5319 llvm-svn: 217697
2014-09-13 01:54:17 +08:00
case Triple::le32: T.setArch(Triple::le64); break;
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
case Triple::mips: T.setArch(Triple::mips64); break;
case Triple::mipsel: T.setArch(Triple::mips64el); break;
This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it. The new target machines are: nvptx (old ptx32) => 32-bit PTX nvptx64 (old ptx64) => 64-bit PTX The sources are based on the internal NVIDIA NVPTX back-end, and contain more functionality than the current PTX back-end currently provides. NV_CONTRIB llvm-svn: 156196
2012-05-05 04:18:50 +08:00
case Triple::nvptx: T.setArch(Triple::nvptx64); break;
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
case Triple::ppc: T.setArch(Triple::ppc64); break;
case Triple::sparc: T.setArch(Triple::sparcv9); break;
case Triple::x86: T.setArch(Triple::x86_64); break;
Add hsail and amdil64 to Triple llvm-svn: 218142
2014-09-20 03:52:11 +08:00
case Triple::amdil: T.setArch(Triple::amdil64); break;
case Triple::hsail: T.setArch(Triple::hsail64); break;
Add support for SPIR64 target - the 64bit counterpart of SPIR. The new OpenCL SPIR extension spec will define separate SPIR for 32 and 64 bit architectures. llvm-svn: 168036
2012-11-15 18:35:47 +08:00
case Triple::spir: T.setArch(Triple::spir64); break;
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
}
return T;
}
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
// FIXME: tblgen this.
const char *Triple::getARMCPUForArch(StringRef MArch) const {
if (MArch.empty())
MArch = getArchName();
switch (getOS()) {
Use armv6k default for FreeBSD/ARM Patch by Andrew Turner. llvm-svn: 217454
2014-09-10 01:47:24 +08:00
case llvm::Triple::FreeBSD:
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
case llvm::Triple::NetBSD:
if (MArch == "armv6")
return "arm1176jzf-s";
break;
case llvm::Triple::Win32:
// FIXME: this is invalid for WindowsCE
return "cortex-a9";
default:
break;
}
const char *result = nullptr;
size_t offset = StringRef::npos;
if (MArch.startswith("arm"))
offset = 3;
if (MArch.startswith("thumb"))
offset = 5;
if (offset != StringRef::npos && MArch.substr(offset, 2) == "eb")
offset += 2;
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
if (MArch.endswith("eb"))
MArch = MArch.substr(0, MArch.size() - 2);
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
if (offset != StringRef::npos)
result = llvm::StringSwitch<const char *>(MArch.substr(offset))
.Cases("v2", "v2a", "arm2")
.Case("v3", "arm6")
.Case("v3m", "arm7m")
.Case("v4", "strongarm")
.Case("v4t", "arm7tdmi")
.Cases("v5", "v5t", "arm10tdmi")
.Cases("v5e", "v5te", "arm1022e")
.Case("v5tej", "arm926ej-s")
[ARM] Add support for ARMV6K subtarget (LLVM) ARMv6K is another layer between ARMV6 and ARMV6T2. This is the LLVM side of the changes. ARMV6 family LLVM implementation. +-------------------------------------+ | ARMV6 | +----------------+--------------------+ | ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors +----------------+--------------------+ have support for hint instructions | ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can +-------------------------------------+ be either real or default to NOP. | ARMV7 (arm,thumb,thumb2) | The two processors also use +-------------------------------------+ different encoding for them. Patch by Vinicius Tinti. llvm-svn: 232468
2015-03-17 19:55:28 +08:00
.Case("v6", "arm1136jf-s")
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
.Case("v6j", "arm1136j-s")
[ARM] Add support for ARMV6K subtarget (LLVM) ARMv6K is another layer between ARMV6 and ARMV6T2. This is the LLVM side of the changes. ARMV6 family LLVM implementation. +-------------------------------------+ | ARMV6 | +----------------+--------------------+ | ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors +----------------+--------------------+ have support for hint instructions | ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can +-------------------------------------+ be either real or default to NOP. | ARMV7 (arm,thumb,thumb2) | The two processors also use +-------------------------------------+ different encoding for them. Patch by Vinicius Tinti. llvm-svn: 232468
2015-03-17 19:55:28 +08:00
.Cases("v6k", "v6z", "v6zk", "arm1176jzf-s")
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
.Case("v6t2", "arm1156t2-s")
[ARM] Add armv6s[-]m as an alias to armv6[-]m llvm-svn: 228696
2015-02-10 23:15:08 +08:00
.Cases("v6m", "v6-m", "v6sm", "v6s-m", "cortex-m0")
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
.Cases("v7", "v7a", "v7-a", "v7l", "v7-l", "cortex-a8")
.Cases("v7s", "v7-s", "swift")
.Cases("v7r", "v7-r", "cortex-r4")
.Cases("v7m", "v7-m", "cortex-m3")
.Cases("v7em", "v7e-m", "cortex-m4")
.Cases("v8", "v8a", "v8-a", "cortex-a53")
[ARM] Rename v8.1a from "extension" to "architecture": follow-up Corrected forgotten change to remove excess "generic-armv8.1-a" cpu Subscribers: llvm-commits Completion of http://reviews.llvm.org/rL233811 llvm-svn: 233903
2015-04-02 17:32:14 +08:00
.Cases("v8.1a", "v8.1-a", "generic")
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
.Default(nullptr);
else
result = llvm::StringSwitch<const char *>(MArch)
.Case("ep9312", "ep9312")
.Case("iwmmxt", "iwmmxt")
.Case("xscale", "xscale")
.Default(nullptr);
if (result)
return result;
// If all else failed, return the most base CPU with thumb interworking
// supported by LLVM.
// FIXME: Should warn once that we're falling back.
switch (getOS()) {
case llvm::Triple::NetBSD:
switch (getEnvironment()) {
case llvm::Triple::GNUEABIHF:
case llvm::Triple::GNUEABI:
case llvm::Triple::EABIHF:
case llvm::Triple::EABI:
return "arm926ej-s";
default:
return "strongarm";
}
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
case llvm::Triple::NaCl:
return "cortex-a8";
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
default:
switch (getEnvironment()) {
case llvm::Triple::EABIHF:
case llvm::Triple::GNUEABIHF:
return "arm1176jzf-s";
default:
return "arm7tdmi";
}
}
}