Commit Graph

259 Commits

Author SHA1 Message Date
Mandeep Singh Grang 083f4d7da4 [OpenEmbedded] Add OpenEmbedded vendor
Summary: The lib paths are not correctly picked up for OpenEmbedded sysroots
(like arm-oe-linux-gnueabi). I fix this in a follow-up clang patch. But in
order to add the correct libs I need to detect if the vendor is oe. For this
reason, it is first necessary to teach llvm to detect oe vendor, which is what
this patch does.

Reviewers: chandlerc, compnerd, rengolin, javed.absar

Reviewed By: compnerd

Subscribers: kristof.beyls, dexonsmith, llvm-commits

Differential Revision: https://reviews.llvm.org/D48861

llvm-svn: 336401
2018-07-05 23:41:17 +00:00
Sjoerd Meijer 195e904002 [ARM][AArch64] Armv8.4-A Enablement
Initial patch adding assembly support for Armv8.4-A.

Besides adding v8.4 as a supported architecture to the usual places, this also
adds target features for the different crypto algorithms. Armv8.4-A introduced
new crypto algorithms, made them optional, and allows different combinations:

- none of the v8.4 crypto functions are supported, which is independent of the
  implementation of the Armv8.0 SHA1 and SHA2 instructions.
- the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0
  SHA1 and SHA2 instructions must also be implemented.
- the v8.4 SM3 and SM4 support is implemented, which is independent of the
  implementation of the Armv8.0 SHA1 and SHA2 instructions.
- all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1
  and SHA2 instructions must also be implemented.

The v8.4 crypto instructions are added to AArch64 only, and not AArch32,
and are made optional extensions to Armv8.2-A.

The user-facing Clang options will map on these new target features, their
naming will be compatible with GCC and added in follow-up patches.

The Armv8.4-A instruction sets can be downloaded here:
https://developer.arm.com/products/architecture/a-profile/exploration-tools

Differential Revision: https://reviews.llvm.org/D48625

llvm-svn: 335953
2018-06-29 08:43:19 +00:00
Adrian Prantl 5f8f34e459 Remove \brief commands from doxygen comments.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

  for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

Differential Revision: https://reviews.llvm.org/D46290

llvm-svn: 331272
2018-05-01 15:54:18 +00:00
Tony Tye 7a893d4e34 [AMDGPU] Remove use of OpenCL triple environment and replace with function attribute for AMDGPU
- Remove use of the opencl and amdopencl environment member of the target triple for the AMDGPU target.
- Use function attribute to communicate to the AMDGPU backend to add implicit arguments for OpenCL kernels for the AMDHSA OS.

Differential Revision: https://reviews.llvm.org/D43736

llvm-svn: 328349
2018-03-23 18:45:18 +00:00
Tony Tye bf320ee335 [AMDGPU] Remove unused AMDOpenCL triple environment
Differential Revision: https://reviews.llvm.org/D43895

llvm-svn: 326745
2018-03-05 21:39:41 +00:00
Jonas Devlieghere 425b248128 [ADT] Recognize ppc as valid architecture in target triple.
Until this patch, only `powerpc` and `ppc32` were recognized as valid
PowerPC 32-bit architectures in a target triple. This was incompatible
with the triple `ppc-apple-darwin` as returned for libObject. I found
out about this when working on a test case using a binary generated on
an old PowerBook G4.

We had the choice of either fix this in the Mach-O object parser or
in the Triple implementation. I chose the latter because it feels like
the most canonical place.

Differential revision: https://reviews.llvm.org/D43760

llvm-svn: 326182
2018-02-27 10:09:58 +00:00
Dan Gohman f2c1cae5cb [WebAssembly] Switch to *-wasm as the default target triple.
This makes wasm32-unknown-unknown-wasm the default, which supports
the .o file writer and the new linking ABI. To enable s2wasm-compatible
output, use the wasm32-unknown-unknown-elf triple.

llvm-svn: 323220
2018-01-23 16:55:44 +00:00
Bob Wilson 7e55e68852 Add a new Simulator entry for the target triple environment.
Apple's iOS, tvOS and watchOS simulator platforms have never been clearly
distinguished in the target triples. Even though they are intended to
behave similarly to the corresponding device platforms, they have separate
SDKs and are really separate platforms from the compiler's perspective.
Clang now defines a macro when building for one of these simulator platforms
(r297866) but that relies on the very indirect mechanism of checking to see
which option was used to specify the minimum deployment target. That is not
so great. Swift would also like to distinguish these simulator platforms in
a similar way, but unlike Clang, Swift does not use a separate option to
specify the minimum deployment target -- it uses a -target option to
specify the target triple directly, including the OS version number.
Using a different target triple for the simulator platforms is a much
more direct and obvious way to specify this. Putting the "simulator" in
the environment component of the triple means the OS values can stay the
same and existing code the looks at the OS field will not be affected.

https://reviews.llvm.org/D39143
rdar://problem/34729432

llvm-svn: 316380
2017-10-23 21:51:50 +00:00
Tim Renouf 9f7ead3334 [Triple] Add AMDPAL operating system type
Summary:
This operating system type represents the AMDGPU PAL runtime, and will
be required by the AMDGPU backend in order to generate correct code for
this runtime.

Currently it generates the same code as not specifying an OS at all.
That will change in future commits.

Patch from Tim Corringham.

Subscribers: arsenm, nhaehnle

Differential Revision: https://reviews.llvm.org/D37380

llvm-svn: 314500
2017-09-29 09:48:12 +00:00
Simon Atanasyan b35dd1c908 [mips] Recognise the triple used by Debian for MIPS n32 ABI
Triples like mips64-linux-gnuabin32 are documented in this article:
https://wiki.debian.org/Multiarch/Tuples

llvm-svn: 313231
2017-09-14 06:50:05 +00:00
Pete Couperus 2d1f6d67c5 [ARC] Add ARC backend.
Add the ARC backend as an experimental target to lib/Target.
Reviewed at: https://reviews.llvm.org/D36331

llvm-svn: 311667
2017-08-24 15:40:33 +00:00
Sam Parker 9d95764c3b [ARM][AArch64] ARMv8.3-A enablement
The beta ARMv8.3 ISA specifications have been released for AArch64
and AArch32, these can be found at:
https://developer.arm.com/products/architecture/a-profile/exploration-tools

An introduction to this architecture update can be found at:
https://community.arm.com/processors/b/blog/posts/armv8-a-architecture-2016-additions

This patch is the first in a series which will add ARM v8.3-A support
in LLVM and Clang. It adds the necessary changes that create targets
for both the ARM and AArch64 backends.

Differential Revision: https://reviews.llvm.org/D36514

llvm-svn: 310561
2017-08-10 09:41:00 +00:00
Florian Hahn 67ddd1d08f [TargetParser] Use enum classes for various ARM kind enums.
Summary:
Using c++11 enum classes ensures that only valid enum values are used
for ArchKind, ProfileKind, VersionKind and ISAKind. This removes the
need for checks that the provided values map to a proper enum value,
allows us to get rid of AK_LAST and prevents comparing values from
different enums. It also removes a bunch of static_cast
from unsigned to enum values and vice versa, at the cost of introducing
static casts to access AArch64ARCHNames and ARMARCHNames by ArchKind.

FPUKind and ArchExtKind are the only remaining old-style enum in
TargetParser.h. I think it's beneficial to keep ArchExtKind as old-style
enum, but FPUKind can be converted too, but this patch is quite big, so
could do this in a follow-up patch. I could also split this patch up a
bit, if people would prefer that.

Reviewers: rengolin, javed.absar, chandlerc, rovka

Reviewed By: rovka

Subscribers: aemerson, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D35882

llvm-svn: 309287
2017-07-27 16:27:56 +00:00
Erich Keane d8f61f8f7e Remove Bitrig: LLVM Changes
Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned.

Differential Revision: https://reviews.llvm.org/D35707

llvm-svn: 308799
2017-07-21 22:48:47 +00:00
Ed Schouten 3370e19725 Add support for Ananas platform
Ananas is a home-brew operating system, mainly for amd64 machines. After
using GCC for quite some time, it has switched to clang and never looked
back - yet, having to manually patch things is annoying, so it'd be much
nicer if this was in the official tree.

More information:

https://github.com/zhmu/ananas/
https://rink.nu/projects/ananas.html

Submitted by:	Rink Springer
Differential Revision:	https://reviews.llvm.org/D32937

llvm-svn: 306237
2017-06-25 08:19:37 +00:00
Florian Hahn 1d38129b92 [Linker] Remove warning when linking ARM and Thumb IR modules.
Summary:
This patch updates Triple::isCompatibleWith to make armxx and thumbxx
triples compatible, as long as the subarch, vendor, os, envorionment and
object format match. Thumb/ARM code generation should be controlled
using the thumb-mode per-function target feature rather than by the
triple to allow mixing Thumb and ARM functions.

D33448 updates Clang's codegen to add thumb-mode for all functions with
armxx or thumbxx triples.

Reviewers: echristo, t.p.northover, rafael, kristof.beyls, rengolin, tejohnson

Reviewed By: tejohnson

Subscribers: rinon, eugenis, pcc, srhines, aemerson, mehdi_amini, javed.absar, llvm-commits

Differential Revision: https://reviews.llvm.org/D33287

llvm-svn: 304884
2017-06-07 09:17:01 +00:00
Chandler Carruth 6bda14b313 Sort the remaining #include lines in include/... and lib/....
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787
2017-06-06 11:49:48 +00:00
Saleem Abdulrasool ac76ec7ce8 ADT: handle special case of ARM environment for SUSE
SUSE treats "gnueabi" as "gnueabihf" so make sure that we normalise the
environment.

llvm-svn: 304670
2017-06-03 22:31:06 +00:00
Jacob Gravelle 26115924a2 Revert r304117 - WebAssembly object format isn't ready to be the default
Summary: Wasm object format has some functionality regressions from the ELF format, and doesn't play nicely with the rest of the toolchain. It should eventually be the default, but not yet.

Reviewers: sunfish, sbc100

Subscribers: jfb, dschuff, llvm-commits

Differential Revision: https://reviews.llvm.org/D33811

llvm-svn: 304512
2017-06-02 01:26:17 +00:00
Nikolai Bozhenov 82f0801c1b [Nios2] Target registration
Reviewers: craig.topper, hfinkel, joerg, lattner, zvi

Reviewed By: craig.topper

Subscribers: oren_ben_simhon, igorb, belickim, tvvikram, mgorny, llvm-commits, pavel.v.chupin, DavidKreitzer

Differential Revision: https://reviews.llvm.org/D32669
Patch by AndreiGrischenko <andrei.l.grischenko@intel.com>

llvm-svn: 304144
2017-05-29 09:48:30 +00:00
Saleem Abdulrasool f122423ace Support: adjust the default obj format for wasm
WebAssemly uses a custom object file format.  For the wasm targets,
default to the `Wasm` object file format.

llvm-svn: 304117
2017-05-29 00:14:57 +00:00
Akira Hatanaka b10bff1183 [ThinLTO] Do not assert when adding a module with a different but
compatible target triple

Currently, an assertion fails in ThinLTOCodeGenerator::addModule when
the target triple of the module being added doesn't match that of the
one stored in TMBuilder. This patch relaxes the constraint and makes
changes to allow target triples that only differ in their version
numbers on Apple platforms, similarly to what r228999 did.

rdar://problem/30133904

Differential Revision: https://reviews.llvm.org/D33291

llvm-svn: 303326
2017-05-18 03:52:29 +00:00
Alex Lorenz c748d7b57b [Triple] Add a "macos" OS type that acts as a synonym for "macosx"
The "macosx" OS type is still the canonical type. In the future "macos" will
become the canonical OS type (but we will still support "macosx").

rdar://27043820

Differential Revision: https://reviews.llvm.org/D32748

llvm-svn: 302011
2017-05-03 10:42:35 +00:00
Ismail Donmez 6dda31729c Add SUSE vendor
Summary: SUSE's ARM triples end with -gnueabi even though they are hard-float. This requires special handling of SUSE ARM triples. Hence we need a way to differentiate the SUSE as vendor. This CL adds that.

Reviewers: chandlerc, compnerd, echristo, rengolin

Reviewed By: rengolin

Subscribers: aemerson, rengolin, llvm-commits

Differential Revision: https://reviews.llvm.org/D32426

llvm-svn: 301174
2017-04-24 11:18:29 +00:00
Brad Smith 159f3bb80e Set default CPU for OpenBSD/arm to Cortex-A8
llvm-svn: 296493
2017-02-28 17:28:35 +00:00
George Burgess IV ccf11c2f9f [ARM] Add support for armv7ve triple in llvm (PR31358).
Gcc supports target armv7ve which is armv7-a with virtualization
extensions. This change adds support for this in llvm for gcc
compatibility.

Also remove redundant FeatureHWDiv, FeatureHWDivARM for a few models as
this is specified automatically by FeatureVirtualization.

Patch by Manoj Gupta.

Differential Revision: https://reviews.llvm.org/D29472

llvm-svn: 294661
2017-02-09 23:29:14 +00:00
Dan Gohman 1209c7ac16 [WebAssembly] Add triple support for the new wasm object format
Differential Revision: https://reviews.llvm.org/D26701

llvm-svn: 292252
2017-01-17 20:34:09 +00:00
Daniel Berlin 4056253c4d Revert "[Triple] Add Facebook vendor"
This reverts commit r287684

Objections on the review thread had not been addressed to
prior to commit.  I asked the committer to revert, but i expect they
are gone for the US holiday or something.

llvm-svn: 287798
2016-11-23 19:03:54 +00:00
Shoaib Meenai 5497121613 [Triple] Add Facebook vendor
Add a compiler vendor for Facebook, to enable future vendor-specific
behavior.

Differential Revision: https://reviews.llvm.org/D25136

llvm-svn: 287684
2016-11-22 19:36:26 +00:00
Pekka Jaaskelainen 8483cf0ae8 Add a little endian variant of TCE.
llvm-svn: 287111
2016-11-16 15:22:23 +00:00
Alex Bradbury b6e784a240 [RISCV] Recognise riscv32 and riscv64 in triple parsing code
This is the first in a series of 10 initial patches that incrementally add an 
MC layer for RISC-V to LLVM. See 
<http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html> for more 
discussion.

Differential Revision: https://reviews.llvm.org/D23557

llvm-svn: 285707
2016-11-01 16:47:54 +00:00
David L Kreitzer 3155abfb57 Define "contiki" OS specifier.
Patch by Michael LeMay

Differential revision: http://reviews.llvm.org/D24897

llvm-svn: 284240
2016-10-14 14:41:46 +00:00
Javed Absar fb4b6e8db9 [ARM]: Add Cortex-R52 target to LLVM
This patch adds Cortex-R52, the new ARM real-time processor, to LLVM. 
Cortex-R52 implements the ARMv8-R architecture.

llvm-svn: 283542
2016-10-07 12:06:40 +00:00
Petr Hosek e023d62e76 [Triple] Add triple for Fuchsia
Fuchsia is a new operating system.

Differential Revision: https://reviews.llvm.org/D25116

llvm-svn: 283419
2016-10-06 05:17:26 +00:00
Mehdi Amini b7fb124512 Use StringRef in Triple API (NFC)
llvm-svn: 282996
2016-10-01 01:16:22 +00:00
Tom Stellard e190cd2834 Triple: Add opencl environment type
Summary:
For AMDGPU, we have been using the operating system component of the triple
for specifying the low-level runtime that is being used.  The rationale for
this is that the host operating system (e.g. Linux) is irrelevant for GPU code,
since its execution enviroment will be mostly controled by the low-level runtime
being used to execute the code.

In most cases, higher level languages have their own runtime which is
implemented on top of the low-level runtime.  The kernel ABIs of each
language mostly depend on the low-level runtime, but there may be some
slight differences between languages.  OpenCL for example, may append
additional arguments to the kernel in order to pass values like global
offsets or buffers for printf.  OpenMP, HCC, or other languages may want
to add their own values which differ from OpenCL.

The reason for adding a new opencl environment type is to make it possible for the backend
to distinguish between the ABIs of the higher-level languages and handle them correctly.
It seems cleaner to use the enviroment component for this rather than creating a new
OS type for every combination of low-level runtime / high-level language.

Reviewers: Anastasia, chandlerc

Subscribers: whchung, pekka.jaaskelainen, wdng, yaxunl, llvm-commits

Differential Revision: https://reviews.llvm.org/D24735

llvm-svn: 282218
2016-09-23 00:42:56 +00:00
Daniel Sanders 2cb55d7dfd [mips] Recognise the triple used by Debian stretch for mips64el.
Summary:
The triple used for this distribution is mips64el-linux-gnuabi64.

Reviewers: sdardis

Subscribers: sdardis, llvm-commits

Differential Revision: https://reviews.llvm.org/D22406

llvm-svn: 275966
2016-07-19 10:22:19 +00:00
Justin Bogner 068a8054ae IR: Set a TargetPrefix for nvvm intrinsics
Since these are named nvvm_* rather than nvptx_*, we also need to
update getArchTypePrefix. It's a bit unusual for getArchTypePrefix not
to match the backend name, but I think this fits the intent of the
function in this case.

llvm-svn: 274890
2016-07-08 17:25:18 +00:00
Pirama Arumuga Nainar 9c3aec2035 Add RenderScript ArchType
Summary:
Add renderscript32 and renderscript64 ArchTypes.  This is to configure
the ABI requirement on 32-bit RenderScript that 'long' types have 64-bit
size and alignment.  64-bit RenderScript is the same as AArch64, but is
added here for completeness.

Reviewers: echristo, rsmith

Subscribers: aemerson, jfb, rampitec, dschuff, mehdi_amini, llvm-commits, srhines

Differential Revision: http://reviews.llvm.org/D21333

llvm-svn: 274412
2016-07-02 00:23:09 +00:00
Davide Italiano 901269c8c9 [Triple] Reimplement isLittleEndian(). Now it works for arm too.
Differential Revision:   http://reviews.llvm.org/D21846

llvm-svn: 274154
2016-06-29 20:01:39 +00:00
Davide Italiano 941685e9f4 [Triple] Add isLittleEndian().
This allows us to query about the endianness without having to
look at DataLayout. The API will be used (and tested) in lld,
in order to find out the endianness of BitcodeFiles.

Briefly discussed with Rafael.

llvm-svn: 274090
2016-06-29 01:56:27 +00:00
Rafael Espindola a895a0cd01 Add support for musl-libc on ARM Linux.
Patch by Lei Zhang!

llvm-svn: 273726
2016-06-24 21:14:33 +00:00
Rafael Espindola 9768b0ae73 Add a Musl environment to the triple.
It will be used in clang.

Patch by Lei Zhang.

llvm-svn: 272660
2016-06-14 12:45:33 +00:00
Matt Arsenault 5e845e54f5 Add AMDGPU related triple vendors/OSes
As support expands to more runtimes, we'll need to
distinguish between more than just HSA and unknown.
This also lets us stop using unknown everywhere.

llvm-svn: 260790
2016-02-13 01:56:21 +00:00
Tim Northover 94bdbd09d7 ARMv7k: use Cortex-A7 by default even for tvOS
Also actually test the default CPU from those triples.

llvm-svn: 260621
2016-02-11 23:49:08 +00:00
Jacques Pienaar dbfe8700cb [lanai] Add Lanai triple.
Add triple for the Lanai backend.

General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend".

Differential Revision: http://reviews.llvm.org/D17003

llvm-svn: 260545
2016-02-11 17:16:20 +00:00
Matt Arsenault 429f28066c AMDGPU: Fix getArchTypePrefix
llvm-svn: 258525
2016-01-22 19:09:12 +00:00
Kelvin Li 510498c0d3 parseArch() supports more variations of arch names for PowerPC builds
llvm-svn: 258103
2016-01-19 00:04:41 +00:00
Bradley Smith e26f799422 [ARM] Add ARMv8-M Baseline/Mainline LLVM targeting
llvm-svn: 257878
2016-01-15 10:24:39 +00:00
Tamas Berghammer 904d5fe496 Mark arm as the 32bit variant of aarch64 in Triple
Change Triple::get32BitArchVariant to return arm/armeb as the 32bit
variant of aarch64/aarch64_be and do the same change for the oppoiste
direction in Triple::get64BitArchVariant.

Differential revision: http://reviews.llvm.org/D15529

llvm-svn: 257048
2016-01-07 10:41:12 +00:00