| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
SUSE treats "gnueabi" as "gnueabihf" so make sure that we normalise the
environment.
llvm-svn: 304670
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
WebAssemly uses a custom object file format. For the wasm targets,
default to the `Wasm` object file format.
llvm-svn: 304117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 296493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26701
llvm-svn: 292252
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Add a compiler vendor for Facebook, to enable future vendor-specific
behavior.
Differential Revision: https://reviews.llvm.org/D25136
llvm-svn: 287684
|
|
|
|
| |
llvm-svn: 287111
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Patch by Michael LeMay
Differential revision: http://reviews.llvm.org/D24897
llvm-svn: 284240
|
|
|
|
|
|
|
| |
This patch adds Cortex-R52, the new ARM real-time processor, to LLVM.
Cortex-R52 implements the ARMv8-R architecture.
llvm-svn: 283542
|
|
|
|
|
|
|
|
| |
Fuchsia is a new operating system.
Differential Revision: https://reviews.llvm.org/D25116
llvm-svn: 283419
|
|
|
|
| |
llvm-svn: 282996
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21846
llvm-svn: 274154
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Lei Zhang!
llvm-svn: 273726
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 258525
|
|
|
|
| |
llvm-svn: 258103
|
|
|
|
| |
llvm-svn: 257878
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
InitMCObjectFileInfo was trying to override the triple in awkward ways.
For example, a triple specifying COFF but not Windows was forced as ELF.
This makes it easy for internal invariants to get violated, such as
those which triggered PR25912.
This fixes PR25912.
llvm-svn: 256226
|
|
|
|
|
|
|
|
|
| |
This creates the initial infrastructure for writing ELF output files. It
doesn't yet have any implementation for encoding instructions.
Differential Revision: http://reviews.llvm.org/D15555
llvm-svn: 255869
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add ARMv8.2-A to TargetParser, so that it can be used by the clang
command-line options and the .arch directive.
Most testing of this will be done in clang, checking that the
command-line options that this enables work.
Differential Revision: http://reviews.llvm.org/D15037
llvm-svn: 254400
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, rengolin
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D14757
llvm-svn: 253676
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch changes ARMV5, ARMV5E, ARMV6SM, ARMV6HL, ARMV7, ARMV7L,
ARMV7HL, ARMV7EM to be treated as aliases for the corresponding
standard architectures, instead of as actual architectures.
Reviewers: rengolin
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14577
llvm-svn: 252903
|
|
|
|
|
|
| |
It's useful for Clang's Driver faff.
llvm-svn: 251574
|
|
|
|
|
|
|
|
| |
These MachO file directives are used by linkers and other tools to provide
compatibility information, much like the existing .ios_version_min and
.macosx_version_min.
llvm-svn: 251569
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
re-using the resulting components rather than repeatedly splitting and
re-splitting to compute each component as part of the initializer list.
This is more work on PR23676. Sadly, it doesn't help much. It removes
the constructor from my profile, but doesn't make a sufficient dent in
the total time. But it should play together nicely with subsequent
changes.
llvm-svn: 247250
|
|
|
|
|
|
|
|
|
|
|
| |
on StringRef. Finding and splitting on a single character is
substantially faster than doing it on even a single character StringRef
-- we immediately get to a *very* tuned memchr call this way.
Even nicer, we get to this even in a debug build, shaving 18% off the
runtime of TripleTest.Normalization, helping PR23676 some more.
llvm-svn: 247244
|