| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 214370
|
| |
|
|
|
|
|
|
|
|
|
| |
Since initializers of GlobalValues are being assigned IDs before
GlobalValues themselves, explicitly exclude GlobalValues from the
constant pool. Added targeted test in `test/Bitcode/use-list-order.ll`
and added two more RUN lines in `test/Assembly`.
This is part of PR5680.
llvm-svn: 214368
|
| |
|
|
|
|
|
|
|
| |
target addresses.
This fixes a mistake where I accidentially dropped the upper 32bit of a
64bit pointer during FastISel lowering of the patchpoint intrinsic.
llvm-svn: 214367
|
| |
|
|
|
|
|
|
|
|
| |
function call lowering.
UNDEF arguments are not ment to be touched - especially for the webkit_js
calling convention. This fix reproduces the already existing behavior of
SelectionDAG in FastISel.
llvm-svn: 214366
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 214364
|
| |
|
|
| |
llvm-svn: 214363
|
| |
|
|
|
|
|
| |
It looks like only direct (i.e., explicitly listed) dependencies are
scanned.
llvm-svn: 214361
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we had
@a = weak global ...
but
@b = alias weak ...
The patch changes aliases to look more like global variables.
Looking at some really old code suggests that the reason was that the old
bison based parser had a reduction for alias linkages and another one for
global variable linkages. Putting the alias first avoided the reduce/reduce
conflict.
The days of the old .ll parser are long gone. The new one parses just "linkage"
and a later check is responsible for deciding if a linkage is valid in a
given context.
llvm-svn: 214355
|
| |
|
|
| |
llvm-svn: 214354
|