| 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
|
|
|
|
|
|
|
|
| |
After the load/store refactoring, we were sometimes trying to feed a
GPR64 into a 32-bit register offset operand. This failed in
copyPhysReg.
llvm-svn: 209566
|
|
|
|
|
|
| |
with swapped input vectors.
llvm-svn: 209495
|
|
|
|
|
|
|
| |
The full string used to be "// =#12" for example, which looks too
busy.
llvm-svn: 209443
|
|
|
|
| |
llvm-svn: 209430
|
|
|
|
| |
llvm-svn: 209429
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Should be no change in behaviour, but it makes the intended
functionality a bit clearer and means we only have to reason about
real extend operations.
llvm-svn: 209409
|
|
|
|
| |
llvm-svn: 209377
|
|
|
|
| |
llvm-svn: 209374
|
|
|
|
| |
llvm-svn: 209373
|
|
|
|
| |
llvm-svn: 209342
|
|
|
|
|
|
|
| |
a subtarget hook to enable. Unconditionally add to the pass pipeline
for targets that might want to use it. No functional change.
llvm-svn: 209340
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Povray and dealII currently assert with "Overran sorted position" in
AssignTopologicalOrder. The problem is that performPostLD1Combine can
introduce cycles.
Consider:
(insert_vector_elt (INSERT_SUBREG undef,
(load (add %vreg0, Constant<8>), undef), <= A
TargetConstant<2>),
(load %vreg0, undef), <= B
Constant<1>)
This is turned into a LD1LANEpost node. However the address in A is not a
valid user of the post-incremented address of B in LD1LANEpost.
llvm-svn: 209242
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When multiple aliases overlap, the correct string to print can often be
determined purely by considering the InstAlias declarations in some particular
order. This allows the user to specify that order manually when desired,
without resorting to hacking around with the default lexicographical order on
Record instantiation, which is error-prone and ugly.
I was also mistaken about "add w2, w3, w4" being the same as "add w2, w3, w4,
uxtw". That's only true if Rn is the stack pointer.
llvm-svn: 209199
|
|
|
|
|
|
|
| |
Patch by Dave Estes<cestes@codeaurora.org>!
PR19761 http://reviews.llvm.org/D3829
llvm-svn: 209176
|
|
|
|
| |
llvm-svn: 209134
|
|
|
|
|
|
| |
case labels. No functional changes intended.
llvm-svn: 209126
|
|
|
|
|
|
|
|
|
|
| |
bswap not.
- On ARM/ARM64 we get a vrev because the shuffle matching code is really smart. We still unroll anything that's not v4i32 though.
- On X86 we get a pshufb with SSSE3. Required more cleverness in isShuffleMaskLegal.
- On PPC we get a vperm for v8i16 and v4i32. v2i64 is unrolled.
llvm-svn: 209123
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a mechanical change changing all the call sites to the newer
chained-function construction pattern. This removes the horrible 15-parameter
constructor for the CallLoweringInfo in favour of setting properties of the call
via chained functions. No functional change beyond the removal of the old
constructors are intended.
llvm-svn: 209082
|
|
|
|
|
|
|
|
|
| |
This is a preliminary step to help ease the construction of CallLoweringInfo.
Changing the construction to a chained function pattern requires that the
parameter be nullable. However, rather than copying the vector, save a pointer
rather than the reference to permit a late binding of the arguments.
llvm-svn: 209080
|
|
|
|
| |
llvm-svn: 209040
|
|
|
|
|
|
|
| |
Patch by Dave Estes <cestes@codeaurora.org>
http://reviews.llvm.org/D3769
llvm-svn: 209001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ldr x1, [x0, #64]
add x0, x0, #64
->
ldr x1, [x0], #64
is not a valid transformation, the correct transformation (and what the code actually does) is:
ldr x1, [x0, #64]
add x0, x0, #64
->
ldr x1, [x0, #64]!
llvm-svn: 208998
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r208934.
The patch depends on aliases to GEPs with non zero offsets. That is not
supported and fairly broken.
The good news is that GlobalAlias is being redesigned and will have support
for offsets, so this patch should be a nice match for it.
llvm-svn: 208978
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TableGen has a fairly dubious heuristic to decide whether an alias should be
printed: does the alias have lest operands than the real instruction. This is
bad enough (particularly with no way to override it), but it should at least be
calculated consistently for both strings.
This patch implements that logic: first get the *correct* string for the
variant, in the same way as the Matcher, without guessing; then count the
number of whitespace chars.
There are basically 4 changes this brings about after the previous
commits; all of these appear to be good, so I have changed the tests:
+ ARM64: we print "neg X, Y" instead of "sub X, xzr, Y".
+ ARM64: we skip implicit "uxtx" and "uxtw" modifiers.
+ Sparc: we print "mov A, B" instead of "or %g0, A, B".
+ Sparc: we print "fcmpX A, B" instead of "fcmpX %fcc0, A, B"
llvm-svn: 208969
|
|
|
|
|
|
|
|
|
| |
The canonical syntax is "fcmXY ..., #0.0".
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208968
|
|
|
|
|
|
|
|
|
|
| |
You can perform (say) an fcmle operation by swapping the operands on an fcmge,
but it shouldn't be printed like that.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208961
|
|
|
|
|
|
|
|
|
|
| |
We accept "ldr w3, [x1, #-1]" as a convenience, but we should still print the
canonical "ldur" form.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208960
|
|
|
|
|
|
|
|
|
|
| |
If an ANDS instruction has Rd == ZR it should be printed as TST since
its only effect is on the flags register NZCV.
This will be tested when the TableGen "should I print this Alias"
heuristic is fixed (very soon).
llvm-svn: 208959
|
|
|
|
|
|
|
|
|
| |
MOV is almost always the right thing to print if possile. People understand it.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208958
|
|
|
|
|
|
|
|
|
|
| |
For example, the full instruction "sub w0, wzr, w1, uxtw" could print as either
"neg w0, w1" or "sub w0, wzr, w1". The former is better.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208957
|
|
|
|
|
|
|
|
|
|
| |
You can write "lslv w0, w1, w2" (probably for legacy reasons), but it should be
printed as simply "lsl".
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
llvm-svn: 208956
|
|
|
|
| |
llvm-svn: 208955
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements two command line switches -global-merge-on-external
and -global-merge-aligned, and both of them are false by default, so this
optimization is disabled by default for all targets.
For ARM64, some back-end behaviors need to be tuned to get this optimization
further enabled.
llvm-svn: 208934
|
|
|
|
| |
llvm-svn: 208902
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, TableGen assumed that every aliased operand consumed precisely 1
MachineInstr slot (this was reasonable because until a couple of days ago,
nothing more complicated was eligible for printing).
This allows a couple more ARM64 aliases to print so we can remove the special
code.
On the X86 side, I've gone for explicit AT&T size specifiers as the default, so
turned off a few of the aliases that would have just started printing.
llvm-svn: 208880
|
|
|
|
|
|
|
|
| |
In all cases, if a "mov" alias exists, it is the canonical form of the
instruction. Now that TableGen can support aliases containing syntax variants,
we can enable them and improve the quality of the asm output.
llvm-svn: 208874
|
|
|
|
|
|
|
| |
To get at least one use of the change (and some actual tests) in with its
commit, I've enabled the AArch64 & ARM64 NEON mov aliases.
llvm-svn: 208867
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 208839
|
|
|
|
|
|
| |
argument stack from callee.
llvm-svn: 208837
|
|
|
|
|
|
| |
inappropriate since it lost its Mask parameter in r154011.
llvm-svn: 208811
|