| 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
|
|
|
|
|
|
|
|
|
|
| |
We should be keeping track of the writeback on these instructions,
otherwise we're relying on LLVM's stupidity for correct code.
Fortunately, the MC layer can now handle all required constraints,
which means we can get rid of the CodeGen only PseudoInsts too.
llvm-svn: 209426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 209134
|
|
|
|
| |
llvm-svn: 208902
|
|
|
|
|
|
|
|
|
| |
Previously, we ignored the difference between V64 and V128 when parsing
assembly: they both got mapped to registers in the FPR128 class. This is
basically harmless at the moment because they both print and encode the same
way. However, it will affect the printing of aliases.
llvm-svn: 208866
|
|
|
|
| |
llvm-svn: 208864
|
|
|
|
| |
llvm-svn: 208863
|
|
|
|
| |
llvm-svn: 208862
|
|
|
|
|
|
| |
emitted
llvm-svn: 208861
|
|
|
|
| |
llvm-svn: 208860
|
|
|
|
|
|
|
|
|
| |
addressing mode.
A vague diagnostic replaced the misleading one.
This can fix bug 19502.
llvm-svn: 208669
|
|
|
|
| |
llvm-svn: 208606
|
|
|
|
|
|
|
|
| |
This is a slightly different approach to AArch64 (the base instruction
definitions aren't quite right for that to work), but achieves the
same thing and reduces C++ hackery in AsmParser.
llvm-svn: 208605
|
|
|
|
|
|
|
| |
If this code triggers, any immediate has already been validated so it can't
possibly trigger a diagnostic.
llvm-svn: 208564
|
|
|
|
|
|
|
|
| |
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: 208540
|
|
|
|
|
|
|
|
| |
Unfortunately, since ARM64 models all these instructions as aliases,
the checks need to be done at the time the alias is seen rather than
during instruction validation as AArch64 does it.
llvm-svn: 208529
|
|
|
|
| |
llvm-svn: 208528
|
|
|
|
|
|
| |
diagnostics
llvm-svn: 208527
|
|
|
|
| |
llvm-svn: 208330
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parsing of ADD/SUB shifted immediates needs to be done explicitly so
that better diagnostics can be emitted, as a side effect this also
removes some of the hacks in the current method of handling this operand
type.
Additionally remove manual CMP aliasing to ADD/SUB and use InstAlias
instead.
llvm-svn: 208329
|
|
|
|
|
|
| |
Also emit a more useful diagnostic when they are not.
llvm-svn: 208318
|
|
|
|
| |
llvm-svn: 208317
|
|
|
|
|
|
|
| |
It doesn't change the results, but it seems silly not to diagnose obvious
problems early on.
llvm-svn: 208083
|
|
|
|
| |
llvm-svn: 208082
|
|
|
|
| |
llvm-svn: 208081
|
|
|
|
|
|
|
| |
No tests here, they'll be added when the entire neon-diagnostics.s test from
AArch64 is enabled.
llvm-svn: 208079
|
|
|
|
| |
llvm-svn: 207742
|
|
|
|
| |
llvm-svn: 207668
|
|
|
|
| |
llvm-svn: 207667
|
|
|
|
|
|
|
|
|
|
| |
It's been decided that in the future, the floating-point immediate in
instructions like "fcmeq v0.2s, v1.2s, #0.0" will be canonically "0.0", which
has been implemented on AArch64 already but not ARM64.
This fixes that issue.
llvm-svn: 207666
|
|
|
|
|
|
| |
Testing will be enabled shortly with basic-a64-instructions.s
llvm-svn: 207648
|
|
|
|
| |
llvm-svn: 207646
|
|
|
|
|
|
|
|
|
|
|
|
| |
AArch64 does not have a CPSR register in the same way that AArch32 does. Most
of its compiler-relevant roles have been taken over by the more specific NZCV
register (representing just the flags set by normal instructions).
Its system control functions still remain, but are now under the
pseudo-register referred to as "PSTATE". They're accessed via various MRS & MSR
instructions described in the reference manual.
llvm-svn: 207645
|
|
|
|
|
|
|
|
|
| |
On instructions using the NZCV register, a couple of conditions have dual
representations: HS/CS and LO/CC (meaning unsigned-higher-or-same/carry-set and
unsigned-lower/carry-clear). The first of these is more descriptive in most
circumstances, so we should print it.
llvm-svn: 207644
|
|
|
|
|
|
|
| |
E.g. we print "ldr x0, [x0, :lo12:symbol]" so we need to accept that syntax
too.
llvm-svn: 207639
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
|
|
|
|
|
| |
Someone couldn't bear to have a completely orthogonal set of floating-point
registers, so we've got some instructions that only accept v0-v15 (coming in
ARMv9, V128_prime: you're allowed v2, v3, v5, v7, ...).
Anyway, we were permitting even the out of range registers during assembly
(CodeGen handled it correctly). This adds a diagnostic.
llvm-svn: 207412
|
|
|
|
| |
llvm-svn: 207197
|
|
|
|
| |
llvm-svn: 207111
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
For now it contains a single flag, SanitizeAddress, which enables
AddressSanitizer instrumentation of inline assembly.
Patch by Yuri Gorshenin.
llvm-svn: 206971
|
|
|
|
|
|
|
|
| |
users.
This completes the porting of r202024 (cpirker "Add AArch64 big endian Target (aarch64_be)") to ARM64.
llvm-svn: 206965
|
|
|
|
|
|
|
|
| |
AArch64 has feature predicates for NEON, FP and CRYPTO instructions.
This allows the compiler to generate code without using FP, NEON
or CRYPTO instructions.
llvm-svn: 206949
|
|
|
|
|
|
|
|
|
| |
The comment claimed that the register class information wasn't available
in the assembly parser, but that's not really true. It's just annoying to
get to. Replace the helper functions with references to the auto-generated
information.
llvm-svn: 206802
|
|
|
|
|
|
|
| |
Make sure only general purpose registers are valid for offset regs and
that 32-bit regs are only valid for sxtw and uxtw extends.
llvm-svn: 206799
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 206798
|