| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
It will be used in clang.
Patch by Lei Zhang.
llvm-svn: 272660
|
|
|
|
|
|
|
|
| |
As support expands to more runtimes, we'll need to
distinguish between more than just HSA and unknown.
This also lets us stop using unknown everywhere.
llvm-svn: 260790
|
|
|
|
|
|
| |
Also actually test the default CPU from those triples.
llvm-svn: 260621
|
|
|
|
|
|
|
|
|
|
| |
Add triple for the Lanai backend.
General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend".
Differential Revision: http://reviews.llvm.org/D17003
llvm-svn: 260545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This follows D14577 to treat ARMv6-J as an alias for ARMv6,
instead of an architecture in its own right.
The functional change is that the default CPU when targeting ARMv6-J
changes from arm1136j-s to arm1136jf-s, which is currently used as
the default CPU for ARMv6; both are, in fact, ARMv6-J CPUs.
The J-bit (Jazelle support) is irrelevant to LLVM, and it doesn't
affect code generation, attributes, optimizations, or anything else,
apart from selecting the default CPU.
Reviewers: rengolin, logan, compnerd
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14755
llvm-svn: 253675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
* ARMv6KZ is the "canonical" name, given in the ARMARM
* ARMv6Z is an "official abbreviation" for it, mentioned in the ARMARM
* ARMv6ZK is a popular misspelling, which we should support as an alias.
The patch corrects the handling of the names.
Functional changes:
* ARMv6Z no longer treated as an architecture in its own right
* ARMv6ZK renamed to ARMv6KZ, accepting ARMv6ZK as an alias
* arm1176jz-s and arm1176jzf-s recognized as ARMv6ZK, instead of ARMv6K
* default ARMv6K CPU changed to arm1176j-s
Reviewers: rengolin, logan, compnerd
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14568
llvm-svn: 253206
|
|
|
|
|
|
|
|
|
|
| |
GNU tools require elfiamcu to take up the entire OS field, so, e.g.
i?86-*-linux-elfiamcu is not considered a legal triple.
Make us compatible.
Differential Revision: http://reviews.llvm.org/D14081
llvm-svn: 251390
|
|
|
|
|
|
|
|
| |
This adds support for the i?86-*-elfiamcu triple, which indicates the IAMCU psABI is used.
Differential Revision: http://reviews.llvm.org/D13977
llvm-svn: 251222
|
|
|
|
|
|
|
|
| |
This patch adds the underlying infrastructure for an AVR backend to be included into LLVM. It is the first of a series of patches aimed at moving the out-of-tree AVR backend into the tree.
It consists of adding a new`Triple` target 'avr'.
llvm-svn: 250492
|
|
|
|
|
|
|
|
|
|
| |
of its strings when expanding the string literals from the macros, and
push all of the APIs to be StringRef instead of C-string APIs.
This (remarkably) removes a very non-trivial number of strlen calls. It
even deletes code and complexity from one of the primary users -- Clang.
llvm-svn: 246374
|
|
|
|
|
|
|
| |
This is used by the AMD x86 OpenCL implementation
to change some ABI details on Windows and Linux.
llvm-svn: 243627
|
|
|
|
|
|
| |
This will be used from clang's driver.
llvm-svn: 241527
|
|
|
|
|
|
|
| |
This unbreaks TripleTest.Normalization. We'll have to come up with a new
plan for the OS component of the target triple for WebAssembly.
llvm-svn: 241041
|
|
|
|
|
|
|
| |
This WebAssembly backend is just a skeleton at this time and is not yet
functional.
llvm-svn: 241022
|
|
|
|
|
|
|
| |
Simple change to make arch like "thumbv6" and "armbev6" to return the
correct CPU for FreeBSD and NetBSD.
llvm-svn: 238353
|
|
|
|
|
|
|
| |
This allows us to match armv6m to default to thumb, but will also be used by
Clang's driver and remove the current incomplete copy in it.
llvm-svn: 238036
|
|
|
|
|
|
|
|
|
|
|
| |
Simplifying Triple::parseARMArch, leaving all the parsing to ARMTargetParser.
This commit also adds AArch64 detection to ARMTargetParser canonicalization,
and a two RedHat arch names (v{6,7}hl, meaning hard-float / little-endian).
Adding enough unit tests to cover the basics. Clang checks fine.
llvm-svn: 237902
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First ARMTargetParser FIXME, conservatively changing the way we parse CPUs
in the back-end. Still not perfect, with a lot of special cases, but moving
towards a more generic solution.
Moving all logic to the target parser made some unwritten assumptions
about architectures in Clang to break. I've added a lot of architectures
required by Clang, and default to CPUs that Clang believes it should
(and I agree).
I've also added a lot of unit tests, with the correct CPU for each
architecture, and Clang seems to be working correctly, too.
It also became clear that using "unsigned ID" as the argument for the get
methods makes it hard to know what ID, so I also changed the argument names
to match the enum type names.
llvm-svn: 237797
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restructure Triple::getARMCPUForArch so that invalid values will
return nullptr, while retaining the behaviour that an argument
specifying no particular architecture version will give a default
CPU. This will be used by clang to give an error on invalid -march
values.
Also restructure the extraction of the architecture version from
the MArch string a little to hopefully make what it's doing clearer.
Differential Revision: http://reviews.llvm.org/D9599
llvm-svn: 236845
|
|
|
|
|
|
|
|
| |
and Redhat currently.
Reviewed by Jonathan Roelofs.
llvm-svn: 236492
|
|
|
|
| |
llvm-svn: 236332
|
|
|
|
|
|
|
|
|
| |
Iteration over all permutations didn't really work,
due to evolution of the underlying enums.
Differential Revision: http://reviews.llvm.org/D9057
llvm-svn: 236251
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9263
llvm-svn: 236139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 218142
|
|
|
|
| |
llvm-svn: 217786
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
llvm::Triple::getARMCPUForArch().
Suggested by Eric Christopher.
llvm-svn: 212846
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
As a bonus I put in some extra checks to make sure that we are identifying the
machine word of various Mac OS X/iOS targets appropriately.
llvm-svn: 173994
|
|
|
|
| |
llvm-svn: 165792
|
|
|
|
|
|
|
|
| |
This back-end was deprecated in favor of the NVPTX back-end.
NV_CONTRIB
llvm-svn: 157417
|
|
|
|
| |
llvm-svn: 156507
|
|
|
|
| |
llvm-svn: 153882
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
some architectures. These are useful for interacting with multiarch or
bi-arch GCC (or GCC-based) toolchains.
llvm-svn: 149895
|
|
|
|
|
|
|
| |
These are very useful for frontends and other utilities reasoning about
or selecting between triples.
llvm-svn: 149353
|
|
|
|
|
|
| |
the loop.
llvm-svn: 124784
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Cameron Esfahani, tweaked to use array_lengthof.
llvm-svn: 114073
|