| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207659
|
|
|
|
|
|
|
| |
The canonical syntax for shifts by a variable amount does not end with 'v', but
that syntax should be supported as an alias (presumably for legacy reasons).
llvm-svn: 207649
|
|
|
|
|
|
| |
Testing will be enabled shortly with basic-a64-instructions.s
llvm-svn: 207648
|
|
|
|
|
|
| |
Testing will be enabled shortly with basic-a64-instructions.s
llvm-svn: 207647
|
|
|
|
| |
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
|
|
|
|
|
|
| |
No functional change, so no tests.
llvm-svn: 207638
|
|
|
|
|
|
|
|
| |
Since these are mostly used in "lsl #16", "lsl #32", "lsl #48" combinations to
piece together an immediate in 16-bit chunks, hex is probably the most
appropriate format.
llvm-svn: 207635
|
|
|
|
|
|
|
|
|
|
| |
This is mostly aimed at the NEON logical operations and MOVI/MVNI (since they
accept weird shifts which are more naturally understandable in hex notation).
Also changes BRK/HINT etc, which is probably a neutral change, but easier than
the alternative.
llvm-svn: 207634
|
|
|
|
|
|
|
|
|
|
| |
Since these instructions only accept a 12-bit immediate, possibly shifted left
by 12, the canonical syntax used by the architecture reference manual is "#N {,
lsl #12 }". We should accept an immediate that has already been shifted, (e.g.
Also, print a comment giving the full addend since it can be helpful.
llvm-svn: 207633
|
|
|
|
|
|
|
| |
v2f32 and v4f32 were missed out of these conditions, so this is also
a bugfix.
llvm-svn: 207628
|
|
|
|
| |
llvm-svn: 207627
|
|
|
|
| |
llvm-svn: 207620
|
|
|
|
|
|
| |
introduced most of these recently.
llvm-svn: 207616
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
| |
is introduced by r207485.
llvm-svn: 207500
|
|
|
|
|
|
| |
E.g. Mask like <-1, -1, 1, ...> will generate incorrect EXT index.
llvm-svn: 207485
|
|
|
|
|
|
| |
D subregister.
llvm-svn: 207423
|
|
|
|
|
|
|
|
|
|
|
| |
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: 207399
|
|
|
|
| |
llvm-svn: 207394
|
|
|
|
| |
llvm-svn: 207377
|
|
|
|
| |
llvm-svn: 207374
|
|
|
|
| |
llvm-svn: 207327
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise the legalizer would just scalarize everything. Support for
mulhi in the targets isn't that great yet so on most targets we get
exactly the same scalarized output. Add a test for x86 vector udiv.
I had to disable the mulhi nodes on ARM because there aren't any patterns
for it. As far as I know ARM has instructions for getting the high part of
a multiply so this should be fixed.
llvm-svn: 207315
|
|
|
|
| |
llvm-svn: 207313
|
|
|
|
|
|
|
|
|
|
|
|
| |
through the GOT
There's no need for local symbols to go through the GOT, in fact it seems GNU ld is not even emitting GOT entries for local symbols and will error out when trying to resolve a GOT relocation for a local symbol.
This bug triggers when bootstrapping clang on AArch64 Linux with -fPIC and the ARM64 backend. The AArch64 backend is not affected.
With this commit it's now possible to bootstrap clang on AArch64 Linux with the ARM64 backend (-fPIC, -O3).
llvm-svn: 207226
|
|
|
|
| |
llvm-svn: 207222
|
|
|
|
|
|
|
|
| |
Also an unused variable, so double bonus!
This should deal with PR19548.
llvm-svn: 207221
|
|
|
|
| |
llvm-svn: 207219
|
|
|
|
|
|
|
|
|
|
| |
no-fp test.
This patch is a supplement of implementing predicate of FP, enabling aarch64 backend
no-fp tests on arm64 target for verification. During this, one bug is exposed and
fixed by this patch.
llvm-svn: 207215
|
|
|
|
|
|
|
| |
According to the specification, CRC is an optional extension of the
architecture.
llvm-svn: 207214
|
|
|
|
| |
llvm-svn: 207197
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to the 'tail' marker, except that it guarantees that
tail call optimization will occur. It also comes with convervative IR
verification rules that ensure that tail call optimization is possible.
Reviewers: nicholas
Differential Revision: http://llvm-reviews.chandlerc.com/D3240
llvm-svn: 207143
|
|
|
|
|
|
|
|
| |
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: 207111
|
|
|
|
| |
llvm-svn: 207110
|
|
|
|
| |
llvm-svn: 207109
|
|
|
|
|
|
| |
We only need assembly support, so it's fairly easy.
llvm-svn: 207108
|
|
|
|
| |
llvm-svn: 207106
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
ARM64 was not producing pure BFI instructions for bitfield insertion
operations, unlike AArch64. The approach had to be a little different (in
ISelDAGToDAG rather than ISelLowering), and the outcomes aren't identical but
hopefully this gives it similar power.
This should address PR19424.
llvm-svn: 207102
|
|
|
|
|
|
|
|
|
| |
ANDS does not use the same encoding scheme as other xxxS instructions (e.g.,
ADDS). Take that into account to avoid wrong peephole optimization.
<rdar://problem/16693089>
llvm-svn: 207020
|
|
|
|
|
|
|
|
|
| |
For now it contains a single flag, SanitizeAddress, which enables
AddressSanitizer instrumentation of inline assembly.
Patch by Yuri Gorshenin.
llvm-svn: 206971
|
|
|
|
| |
llvm-svn: 206967
|
|
|
|
|
|
|
|
| |
users.
This completes the porting of r202024 (cpirker "Add AArch64 big endian Target (aarch64_be)") to ARM64.
llvm-svn: 206965
|