| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add frontend tests for Cortex-A75 and Cortex-A55, Arm's latest
big.LITTLE A-class cores. They implement the ARMv8.2-A architecture,
including the cryptography and RAS extensions, plus the optional dot
product extension. They also implement the RCpc AArch64 extension
from ARMv8.3-A.
Cortex-A75:
https://developer.arm.com/products/processors/cortex-a/cortex-a75
Cortex-A55:
https://developer.arm.com/products/processors/cortex-a/cortex-a55
Differential Revision: https://reviews.llvm.org/D36731
llvm-svn: 311319
|
|
|
|
|
|
|
| |
It was committed by mistake since it was in the same monorepo as the
LLVM change I was working on.
llvm-svn: 311140
|
|
|
|
|
|
|
|
| |
If a struct would end up half in GPRs and half on SP the ABI says it should
actually go entirely on the stack. We were getting this wrong in GlobalISel
before, causing compatibility issues.
llvm-svn: 311137
|
|
|
|
|
|
|
|
| |
Bring back changes which r304953 introduced since
they were in fact not the cause of failures described
in r310057 commit message.
llvm-svn: 310702
|
|
|
|
|
|
|
|
|
|
| |
While we do not support `-mshared / -mno-shared` properly, show warning
and ignore `-mlong-calls` option in case of implicitly or explicitly
provided `-mabicalls` option.
Differential revision: https://reviews.llvm.org/D36551
llvm-svn: 310614
|
|
|
|
|
|
|
|
|
|
| |
The -mabicalls option does not make sense in the case of non position
independent code for the N64 ABI. After this change the driver shows a
warning that -mabicalls is ignored in that case.
Differential revision: https://reviews.llvm.org/D36550
llvm-svn: 310613
|
|
|
|
|
|
|
|
|
|
| |
This is causing failures when compiling clang with -O3
as one of the structures used by clang is passed by
value and uses the fastcc calling convention.
Faliures manifest for stage2 mips build.
llvm-svn: 310057
|
|
|
|
| |
llvm-svn: 310037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This updates the relevant Clang parts for the LLVM change D35882.
Reviewers: rengolin, chandlerc, javed.absar, rovka
Reviewed By: rovka
Subscribers: aemerson, cfe-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D35884
llvm-svn: 309289
|
|
|
|
|
|
|
|
|
| |
This just adds the CPU to a list of commands passed to GAS when not using the
integrated assembler.
Differential Revision: https://reviews.llvm.org/D33820
llvm-svn: 309256
|
|
|
|
|
|
|
|
| |
Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned.
Differential Revision: https://reviews.llvm.org/D35708
llvm-svn: 308797
|
|
|
|
|
|
|
|
| |
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35254
llvm-svn: 307847
|
|
|
|
|
|
| |
GNUEABIHF.
llvm-svn: 307665
|
|
|
|
|
|
|
|
| |
Check the `-mlong-calls` command line option and pass the `long-calls`
feature flag to the backend. Handling of this feature flag in the backend
needs to be implemented by a separate commit.
llvm-svn: 307386
|
|
|
|
|
|
| |
flags. NFC
llvm-svn: 307152
|
|
|
|
| |
llvm-svn: 307151
|
|
|
|
|
|
| |
use subtarget feature rather than command line option.
llvm-svn: 306928
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test in r304929 broke multiple buildbots as it expected mips target to
be registered and available (which is not necessarily true). Updating the
test with this condition.
Original commit:
[mips] Add runtime options to enable/disable madd.fmt and msub.fmt
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
llvm-svn: 304953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert r304929 since the test broke buildbots.
Original commit:
[mips] Add runtime options to enable/disable madd.fmt and msub.fmt
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
llvm-svn: 304935
|
|
|
|
|
|
|
|
|
|
|
| |
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D33401
llvm-svn: 304929
|
|
|
|
| |
llvm-svn: 302590
|
|
|
|
|
|
| |
was removed from the backend.
llvm-svn: 299416
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: olista01, rengolin, javed.absar, samparker
Reviewed By: samparker
Subscribers: samparker, llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D31197
llvm-svn: 298850
|
|
|
|
|
|
|
|
|
|
|
| |
The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.
Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.
llvm-svn: 298449
|
|
|
|
| |
llvm-svn: 298097
|
|
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
|