| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit starts with a "git mv ARM64 AArch64" and continues out
from there, renaming the C++ classes, intrinsics, and other
target-local objects for consistency.
"ARM64" test directories are also moved, and tests that began their
life in ARM64 use an arm64 triple, those from AArch64 use an aarch64
triple. Both should be equivalent though.
This finishes the AArch64 merge, and everyone should feel free to
continue committing as normal now.
llvm-svn: 209577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm doing this in two phases for a better "git blame" record. This
commit removes the previous AArch64 backend and redirects all
functionality to ARM64. It also deduplicates test-lines and removes
orphaned AArch64 tests.
The next step will be "git mv ARM64 AArch64" and rewire most of the
tests.
Hopefully LLVM is still functional, though it would be even better if
no-one ever had to care because the rename happens straight
afterwards.
llvm-svn: 209576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes ARM64 to use separate operands for each component of an
address, and look for separate '[', '$Rn, ..., ']' tokens when
parsing.
This allows us to do away with quite a bit of special C++ code to
handle monolithic "addressing modes" in the MC components. The more
incremental matching of the assembler operands also allows for better
diagnostics when LLVM is presented with invalid input.
Most of the complexity here is with the register-offset instructions,
which were extremely dodgy beforehand: even when the instruction used
wM, LLVM's model had xM as an operand. We papered over this
discrepancy before, but that approach doesn't work now so I split them
into separate X and W variants.
llvm-svn: 209425
|
|
|
|
|
|
| |
Reviewed at http://reviews.llvm.org/D3741
llvm-svn: 208792
|
|
|
|
|
|
|
|
| |
In terms of assembly, these have too much overlap to be neatly modelled as
disjoint classes: in many cases "lsl" is an acceptable alternative to either
"uxtw" or "uxtx".
llvm-svn: 208563
|
|
|
|
| |
llvm-svn: 207668
|
|
|
|
| |
llvm-svn: 207627
|
|
|
|
|
|
| |
'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. ARM64 edition
llvm-svn: 207509
|
|
|
|
| |
llvm-svn: 207394
|
|
|
|
| |
llvm-svn: 207197
|
|
|
|
|
|
|
|
| |
I discovered this const-hole while attempting to coalesnce the Symbol
and SymbolMap data structures. There's some pending issues with that,
but I figured this change was easy to flush early.
llvm-svn: 207124
|
|
|
|
| |
llvm-svn: 207110
|
|
|
|
| |
llvm-svn: 207109
|
|
|
|
|
|
| |
We only need assembly support, so it's fairly easy.
llvm-svn: 207108
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These can have different relocations in ELF. In particular both:
b.eq global
ldr x0, global
are valid, giving different relocations. The only possible way to distinguish
them is via a different fixup, so the operands had to be separated throughout
the backend.
llvm-svn: 207105
|
|
|
|
|
|
|
|
| |
users.
This completes the porting of r202024 (cpirker "Add AArch64 big endian Target (aarch64_be)") to ARM64.
llvm-svn: 206965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostic that includes location information.
Currently if one has this assembly:
.quad (0x1234 + (4 * SOME_VALUE))
where SOME_VALUE is undefined ones gets the less than
useful error message with no location information:
% clang -c x.s
clang -cc1as: fatal error: error in backend: expected relocatable expression
With this fix one now gets a more useful error message
with location information:
% clang -c x.s
x.s:5:8: error: expected relocatable expression
.quad (0x1234 + (4 * SOME_VALUE))
^
To do this I plumbed the SMLoc through the MCObjectStreamer
EmitValue() and EmitValueImpl() interfaces so it could be used
when creating the MCFixup.
rdar://12391022
llvm-svn: 206906
|
|
|
|
|
|
|
| |
definition below all of the header #include lines, lib/Target/...
edition.
llvm-svn: 206842
|
|
|
|
|
|
|
|
|
|
|
|
| |
system headers above the includes of generated '.inc' files that
actually contain code. In a few targets this was already done pretty
consistently, but it wasn't done *really* consistently anywhere. It is
strictly cleaner IMO and necessary in a bunch of places where the
DEBUG_TYPE is referenced from the generated code. Consistency with the
necessary places trumps. Hopefully the build bots are OK with the
movement of intrin.h...
llvm-svn: 206838
|
|
|
|
| |
llvm-svn: 206391
|
|
|
|
| |
llvm-svn: 206378
|
|
|
|
|
|
|
|
| |
Sometimes we need emit the bits that would actually be a MOVN when producing a
relocated MOVZ instruction (don't ask). But not always, a check which ARM64 got
wrong until now.
llvm-svn: 206289
|
|
|
|
| |
llvm-svn: 206228
|
|
|
|
|
|
|
|
| |
This matches that ARM64Subtarget does for now.
This is related to <rdar://problem/16573920>
llvm-svn: 206211
|
|
|
|
| |
llvm-svn: 205899
|
|
|
|
|
|
| |
zero but should be decoded/disassembled with any value.
llvm-svn: 205883
|
|
|
|
| |
llvm-svn: 205877
|
|
|
|
|
|
| |
stores, so the unused register fields are set to all-ones canonically but are recognised with any value.
llvm-svn: 205874
|
|
|
|
| |
llvm-svn: 205872
|
|
|
|
|
|
| |
These files are required in the decoder, disassembler and parser, and a layering violation was imminent.
llvm-svn: 205867
|
|
|
|
|
|
| |
AArch64. AArch64's named immediate mapping and parsing is much more advanced than ARM64's. No functionality change - they're currently living side by side while I switch uses over.
llvm-svn: 205866
|
|
|
|
|
|
| |
assembly/disassembly, equivilant to AL)
llvm-svn: 205864
|
|
|
|
|
|
| |
implicitly. No functional change intended.
llvm-svn: 205304
|
|
|
|
| |
llvm-svn: 205301
|
|
|
|
|
|
|
|
|
| |
It was doing functional but highly suspect operations on bools due to
the more limited shifting operands supported by memory instructions.
Should fix some MSVC warnings.
llvm-svn: 205134
|
|
|
|
| |
llvm-svn: 205112
|
|
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
|