| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 214494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Big-endian mode was not correctly adjusting the offset for types smaller
than an ABI slot.
Fixes PR19612
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: sstankovic, llvm-commits
Differential Revision: http://reviews.llvm.org/D4556
llvm-svn: 214493
|
| |
|
|
| |
llvm-svn: 214487
|
| |
|
|
|
|
|
|
| |
operands.
This reverts r214338 (except the test file) and replaces it with a more general algorithm.
llvm-svn: 214485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regular loads
Altivec vector loads on PowerPC have an interesting property: They always load
from an aligned address (by rounding down the address actually provided if
necessary). In order to generate an actual unaligned load, you can generate two
load instructions, one with the original address, one offset by one vector
length, and use a special permutation to extract the bytes desired.
When this was originally implemented, I generated these two loads using regular
ISD::LOAD nodes, now marked as aligned. Unfortunately, there is a problem with
this:
The alignment of a load does not contribute to its identity, and SDNodes
are uniqued. So, imagine that we have some unaligned load, L1, that is not
aligned. The routine will create two loads, L1(aligned) and (L1+16)(aligned).
Further imagine that there had already existed a load (L1+16)(unaligned) with
the same chain operand as the load L1. When (L1+16)(aligned) is created as part
of the lowering of L1, this load *is* also the (L1+16)(unaligned) node, just
now marked as aligned (because the new alignment overwrites the old). But the
original users of (L1+16)(unaligned) now get the data intended for the
permutation yielding the data for L1, and (L1+16)(unaligned) no longer exists
to get its own permutation-based expansion. This was PR19991.
A second potential problem has to do with the MMOs on these loads, which can be
used by AA during instruction scheduling to break chain-based dependencies. If
the new "aligned" loads get the MMO from the original unaligned load, this does
not represent the fact that it will load data from below the original address.
Normally, this would not matter, but this load might be combined with another
load pair for a previous vector, and then the dependency on the otherwise-
ignored lower bytes can matter.
To fix both problems, instead of generating the necessary loads using regular
ISD::LOAD instructions, ppc_altivec_lvx intrinsics are used instead. These are
provided with MMOs with a conservative address range.
Unfortunately, I no longer have a failing test case (since PR19991 was
reported, other changes in CodeGen have forced this bug back into hiding it
again). Nevertheless, this should fix the underlying problem.
llvm-svn: 214481
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4653
llvm-svn: 214479
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4628
llvm-svn: 214478
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4652
llvm-svn: 214477
|
| |
|
|
|
|
|
|
| |
Patch Credit to Ankit Jain !
Differential Revision: http://reviews.llvm.org/D4655
llvm-svn: 214476
|
| |
|
|
| |
llvm-svn: 214475
|
| |
|
|
|
|
|
|
|
|
|
|
| |
{s|u}{add|sub}.with.overflow intrinsics.
ADDS and SUBS cannot encode negative immediates or immediates larger than 12bit.
This fix checks if the immediate version can be used under this constraints and
if we can convert ADDS to SUBS or vice versa to support negative immediates.
Also update the test cases to test the immediate versions.
llvm-svn: 214470
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating unaligned vector loads, we need to search for other loads or
stores nearby offset by one vector width. If we find one, then we know that we
can safely generate another aligned load at that address. Otherwise, we must
generate the next load using an offset of the vector width minus one byte (so
we don't read off the end of the allocation if the base unaligned address
happened to be aligned at runtime). We had previously done this using only
other vector loads and stores, but did not consider the PowerPC-specific vector
load/store intrinsics. Now we'll also consider vector intrinsics. By itself,
this change is a feature enhancement, but is a necessary step toward fixing the
underlying problem behind PR19991.
llvm-svn: 214469
|
| |
|
|
|
|
|
|
| |
This improves the diagnostics from the regular assembler, but more
importantly it fixes an assertion when parsing inline assembly. Test
landing in Clang.
llvm-svn: 214468
|
| |
|
|
|
|
|
|
|
|
| |
Abs/neg folding has moved out of foldOperands and into the instruction
selection phase using complex patterns. As a consequence of this
change, we now prefer to select the 64-bit encoding for most
instructions and the modifier operands have been dropped from
integer VOP3 instructions.
llvm-svn: 214467
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We were incorrectly assuming that all VOP2 instructions can read SGPRs
in Src0, but this is not true for instructions that read carry-in from
VCC.
The old logic has been replaced with new logic which checks the defined
register classes of the VOP2 instruction to determine whether or not to
legalize the operands.
llvm-svn: 214465
|
| |
|
|
|
|
|
| |
This will prevent us from using extra MOV instructions once we prefer
selecting 64-bit instructions.
llvm-svn: 214464
|
| |
|
|
|
|
|
|
| |
We were commuting the instruction by still shrinking it using the
original opcode.
NOTE: This is a candidate for the 3.5 branch.
llvm-svn: 214463
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This allows assembling the two new instructions, encls and enclu for the
SKX processor model.
Note the diffs are a bigger than what might think, but to fit the new
MRM_CF and MRM_D7 in things in the right places things had to be
renumbered and shuffled down causing a bit more diffs.
rdar://16228228
llvm-svn: 214460
|
| |
|
|
|
|
|
|
| |
Instead, create an absolute memory operand.
Fixes PR20504.
llvm-svn: 214457
|
| |
|
|
|
|
| |
Previously we would execute unreachable during object emission.
llvm-svn: 214456
|
| |
|
|
| |
llvm-svn: 214455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when DAGCombine converts loads feeding a switch into a switch of
addresses feeding a load the new load inherits the isInvariant flag of the left
side. This is incorrect since invariant loads can be reordered in cases where it
is illegal to reoarder normal loads.
This patch adds an isInvariant parameter to getExtLoad() and updates all call
sites to pass in the data if they have it or false if they don't. It also
changes the DAGCombine to use that data to make the right decision when
creating the new load.
llvm-svn: 214449
|
| |
|
|
|
|
|
|
| |
The current remark is ambiguous and makes it sounds like explicitly specifying vectorization will allow the loop to be vectorized. This is not the case. The improved remark directs the user to -Rpass-analysis=loop-vectorize to determine the cause of the pass-miss.
Reviewed by Arnold Schwaighofer`
llvm-svn: 214445
|
| |
|
|
|
|
|
|
| |
is apparently used, but the build didn't return errors weirdly.
This reverts commits 214437 and 214438.
llvm-svn: 214444
|
| |
|
|
|
|
|
|
| |
is not a reduction or induction variable.
Reviewed by Arnold Schwaighofer
llvm-svn: 214440
|
| |
|
|
| |
llvm-svn: 214438
|
| |
|
|
| |
llvm-svn: 214437
|
| |
|
|
|
|
| |
Thanks to David Blaikie for noticing it.
llvm-svn: 214434
|
| |
|
|
|
|
| |
This makes using a std::unique_ptr in the caller more convenient.
llvm-svn: 214433
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to the activity in the bug at
http://llvm.org/bugs/show_bug.cgi?id=18663 . The underlying issue has
to do with how the KILL pseudo-instruction is handled. I defer to
Hal/Jakob/Uli for additional details and background.
This will disable the (bad?) assert, add an associated fixme comment,
and add a pair of tests.
The code change and the pr18663-2.ll test are copied from the referenced
bug. That test does not immediately fail in my environment, but I have
added the pr18663.ll test which does.
(Comment from Hal)
to provide everyone else with some context, this assert was not bad when
it was written. At that time, we only generated KILL pseudo instructions
around subregister copies. This logic, unfortunately, had its own problems.
In r199797, the relevant logic in MachineCopyPropagation was replaced to
generate KILLs for other kinds of copies too. This change in semantics broke
this now-problematic assumption in AggressiveAntiDepBreaker. The
AggressiveAntiDepBreaker really needs a proper cleanup to deal with the
change, but removing the assert (which just allows the function to return
false) is a safe conservative behavior, and should do for the time being.
llvm-svn: 214429
|
| |
|
|
|
|
| |
The cpp file is already in lib/MC/MCAnalysis.
llvm-svn: 214424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
predecessors
It seems that when I fixed this, almost exactly a year ago, I did not quite do
it correctly. When we have duplicate block predecessors, we can indeed not have
different incoming values for the same block, but we *must* have duplicate
entries. So, instead of skipping the duplicates, we explicitly add the
duplicate incoming values.
Fixes PR20442.
llvm-svn: 214423
|
| |
|
|
|
|
|
|
|
|
| |
Correctly sort self-users (such as PHI nodes). I added a targeted test
in `test/Bitcode/use-list-order.ll` and the final missing RUN line to
tests in `test/Assembly`.
This is part of PR5680.
llvm-svn: 214417
|
| |
|
|
|
| |
Note: This code appears to be untested.
llvm-svn: 214416
|
| |
|
|
|
|
| |
function as well. No functional changes intended.
llvm-svn: 214400
|
| |
|
|
| |
llvm-svn: 214399
|
| |
|
|
|
|
|
|
| |
Switch array type shadow from a single integer to
an array of integers (i.e. make it per-element).
This simplifies instrumentation of extractvalue and fixes PR20493.
llvm-svn: 214398
|
| |
|
|
|
|
| |
Patch by Yuri Gorshenin.
llvm-svn: 214395
|
| |
|
|
|
|
| |
cmpOperation has been renamed to cmpOperations (multiple form).
llvm-svn: 214392
|
| |
|
|
|
|
|
|
| |
and int.
Fixes <rdar://problem/17867078>.
llvm-svn: 214389
|
| |
|
|
|
|
| |
Fixes <rdar://problem/17867067>.
llvm-svn: 214388
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We can only propagate the nsw bits if both subtraction instructions are
marked with the appropriate bit.
N.B. We only propagate the nsw bit in InstCombine because the nuw case
is already handled in InstSimplify.
This fixes PR20189.
llvm-svn: 214385
|
| |
|
|
|
|
|
|
|
|
|
| |
If the NUW bit is set for 0 - Y, we know that all values for Y other
than 0 would produce a poison value. This allows us to replace (0 - Y)
with 0 in the expression (X - (0 - Y)) which will ultimately leave us
with X.
This partially fixes PR20189.
llvm-svn: 214384
|
| |
|
|
|
|
|
|
|
| |
Currently the large code model for MachO uses the GOT to make function calls.
Emit the required adrp and ldr instructions to load the address from the GOT.
Related to <rdar://problem/17733076>.
llvm-svn: 214381
|
| |
|
|
| |
llvm-svn: 214379
|
| |
|
|
| |
llvm-svn: 214377
|
| |
|
|
|
|
|
|
| |
Instead allow the variable to be declared, but don't attach an initializer. This allows more than a single error to be emitted before we exit.
Test case to follow soon in another patch.
llvm-svn: 214375
|
| |
|
|
|
|
|
|
| |
This is currently for assigning from one bit init to another. It can easily be extended to other types.
Test to follow soon in another patch.
llvm-svn: 214374
|
| |
|
|
|
|
| |
silently dropped the leading 0
llvm-svn: 214373
|
| |
|
|
|
|
| |
silently dropped the leading 0
llvm-svn: 214372
|