summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Triple.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Add support for Nuxi CloudABI.Ed Schouten2015-03-091-0/+2
| | | | | | | | | | | | | | 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
* Make Triple::getOSVersion make sense for Android.Dan Albert2015-03-031-0/+8
| | | | | | | | | | | | Reviewers: srhines Reviewed By: srhines Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7928 llvm-svn: 231090
* Triple: Make setEnvironment not override the object formatReid Kleckner2015-02-131-1/+5
| | | | | | | | | | | | | | | 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
* [ARM] Add armv6s[-]m as an alias to armv6[-]mBradley Smith2015-02-101-2/+3
| | | | llvm-svn: 228696
* The canonical CPU variant for ARM according to config.guess uses aJoerg Sonnenberger2015-01-261-5/+21
| | | | | | | | | | | | | | | | 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
* Add the triple for the Sony Playstation®4.Alex Rosenberg2015-01-251-0/+2
| | | | | | Lots more to follow. llvm-svn: 227060
* BPF backendAlexei Starovoitov2015-01-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Triple: Add amdgcn tripleTom Stellard2015-01-061-1/+8
| | | | | | | This will be used for AMD GPUs with the Graphics Core Next architecture, which are currently using by the r600 triple. llvm-svn: 225276
* Triple: Add AMDHSA operating system typeTom Stellard2014-12-021-0/+2
| | | | | | | | 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
* Fix ARM triple parsingRenato Golin2014-11-171-13/+48
| | | | | | | | | 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
* Add hsail and amdil64 to TripleMatt Arsenault2014-09-191-5/+29
| | | | llvm-svn: 218142
* Add support for le64.JF Bastien2014-09-121-2/+9
| | | | | | | | | | | | | | | | | 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
* Use armv6k default for FreeBSD/ARMEd Maste2014-09-091-0/+1
| | | | | | Patch by Andrew Turner. llvm-svn: 217454
* Removed white-spaceMatthew Gardiner2014-09-051-2/+0
| | | | llvm-svn: 217230
* Adding kalimba variants as Triple sub-architectures.Matthew Gardiner2014-09-051-1/+6
| | | | | | | | Reviewed in: http://reviews.llvm.org/D5115 llvm-svn: 217229
* Delete support for AuroraUX.Rafael Espindola2014-08-141-2/+0
| | | | | | | | | auroraux.org is not resolving. I will add this to the release notes as soon as I figure out where to put the 3.6 release notes :-) llvm-svn: 215645
* ADT: remove MinGW32 and Cygwin OSType enumSaleem Abdulrasool2014-08-091-9/+13
| | | | | | | | | | | 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
* Remove dead code.Rafael Espindola2014-07-251-28/+0
| | | | llvm-svn: 213963
* AArch64: remove "arm64_be" support in favour of "aarch64_be".Tim Northover2014-07-231-2/+0
| | | | | | | | | There really is no arm64_be: it was a useful fiction to test big-endian support while both backends existed in parallel, but now the only platform that uses the name (iOS) doesn't have a big-endian variant, let alone one called "arm64_be". llvm-svn: 213748
* AArch64: remove arm64 triple enumerator.Tim Northover2014-07-231-16/+5
| | | | | | | | | | | | 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
* Add MIPS Technologies to the vendors in llvm::Triple.Daniel Sanders2014-07-181-0/+2
| | | | | | | | 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
* Refactor ARM subarchitecture parsingRenato Golin2014-07-181-0/+25
| | | | | | | | | Re-commit of a patch to rework the triple parsing on ARM to a more sane model. Patch by Gabor Ballabas. llvm-svn: 213367
* Fix the prefix for arm64 tripleYi Kong2014-07-171-3/+2
| | | | | | | | | | | | Triple.cpp still returns "arm64" as prefix for arm64 triple, causing Clang not being able to select the correct GCCBuiltin IR. This patch changes the value to correct prefix "aarch64". Regression test will be added in the coming patch. Differential Revision: http://reviews.llvm.org/D4516 llvm-svn: 213240
* Move the API and implementation of clang::driver::getARMCPUForMArch() to ↵Argyrios Kyrtzidis2014-07-111-0/+82
| | | | | | | | llvm::Triple::getARMCPUForArch(). Suggested by Eric Christopher. llvm-svn: 212846
* Add the CSR company and the Kalimba DSP processor to Triple.Eric Christopher2014-07-101-0/+9
| | | | | | Patch by Matthew Gardiner with fixes by me. llvm-svn: 212745
* Add Imagination Technologies to the vendors in llvm::TripleDaniel Sanders2014-07-091-0/+2
| | | | | | | | 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
* Fix some Twine locals.Benjamin Kramer2014-07-081-3/+2
| | | | | | Two of those are use after frees. Found by clang-tidy, fixed by me. llvm-svn: 212537
* Revert "Refactor ARM subarchitecture parsing"Renato Golin2014-07-081-23/+0
| | | | | | This reverts commit 7b4a6882467e7fef4516a0cbc418cbfce0fc6f6d. llvm-svn: 212521
* Refactor ARM subarchitecture parsingRenato Golin2014-07-071-0/+23
| | | | | | | | | According to a FIXME in ARMMCTargetDesc.cpp the ARM version parsing should be in the Triple helper class. Patch by: Gabor Ballabas llvm-svn: 212479
* [ARM64] Add big endian target arm64_be.James Molloy2014-04-141-1/+9
| | | | llvm-svn: 206197
* [C++11] Make use of 'nullptr' in the Support library.Craig Topper2014-04-071-3/+3
| | | | llvm-svn: 205697
* Support: generalise object type handling for WindowsSaleem Abdulrasool2014-03-311-7/+15
| | | | | | | | | 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
* ARM64: remove -m32/-m64 mapping with ARM.Tim Northover2014-03-301-2/+2
| | | | | | | 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
* Support: correct Windows normalisationSaleem Abdulrasool2014-03-301-2/+12
| | | | | | | | | | | | | 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
* ARM64: initial backend importTim Northover2014-03-291-3/+13
| | | | | | | | | | | | 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
* Add ARM big endian Target (armeb, thumbeb)Christian Pirker2014-03-281-1/+18
| | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
* Canonicalise Windows target triple spellingsSaleem Abdulrasool2014-03-271-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix inconsistent whitespace.Bob Wilson2014-03-091-1/+1
| | | | llvm-svn: 203423
* Support: split object format out of environmentSaleem Abdulrasool2014-03-061-7/+45
| | | | | | | | | | | 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
* Add AArch64 big endian Target (aarch64_be)Christian Pirker2014-02-241-42/+49
| | | | llvm-svn: 202024
* [x86] Support i386-*-*-code16 triple for emitting 16-bit codeDavid Woodhouse2014-01-201-0/+2
| | | | llvm-svn: 199648
* Recognize EABIHF as environment and use it for RTAPI + VFP.Joerg Sonnenberger2013-12-161-0/+2
| | | | llvm-svn: 197405
* Darwin: update default iOS version to 5.0Tim Northover2013-12-101-3/+3
| | | | | | | | | | | | 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
* X86: Encode the 'h' cpu subtype in the MachO header for x86.Jim Grosbach2013-11-161-1/+1
| | | | llvm-svn: 194906
* [PowerPC] Support powerpc64le as a syntax-checking target.Bill Schmidt2013-07-261-0/+8
| | | | | | | | | | | | | | | | | | | | | | | 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
* Remove the mblaze backend from llvm.Rafael Espindola2013-07-251-9/+0
| | | | | | Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html llvm-svn: 187145
* [NVPTX] Add support for selecting CUDA vs OCL mode based on tripleJustin Holewinski2013-06-211-0/+6
| | | | | | IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl" llvm-svn: 184579
* Recognize sparc64 as an alias for sparcv9 triples.Jakob Stoklund Olesen2013-05-141-1/+1
| | | | | | Patch by Brad Smith! llvm-svn: 181808
* [SystemZ] Add llvm::Triple::systemzRichard Sandiford2013-05-031-0/+8
| | | | | | | First step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. llvm-svn: 181007
* Add AArch64 as an experimental target.Tim Northover2013-01-311-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud