| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
There were a few cases introduced with the modulo scheduler.
llvm-svn: 277358
|
| |
|
|
|
|
|
|
|
| |
Scavenging slots were only reserved when pseudo-instruction expansion in
frame lowering created new virtual registers. It is possible to still
need a scavenging slot even if no virtual registers were created, in cases
where the stack is large enough to overflow instruction offsets.
llvm-svn: 277355
|
| |
|
|
| |
llvm-svn: 277349
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Allocating an AFGR64 shadows two GPR32's instead of just one.
This fixes an LNT regression detected by our internal buildbots.
Reviewers: sdardis
Subscribers: dsanders, sdardis, llvm-commits
Differential Revision: https://reviews.llvm.org/D23012
llvm-svn: 277348
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D22522
llvm-svn: 277344
|
| |
|
|
|
|
| |
Similar to the regular shift instructions, SHLD/SHRD only use the bottom bits of the shift value
llvm-svn: 277341
|
| |
|
|
| |
llvm-svn: 277337
|
| |
|
|
| |
llvm-svn: 277333
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using RAUW was wrong here; if we have a switch transform such as:
18 -> 6 then
6 -> 0
If we use RAUW, while performing the second transform the *transformed* 6
from the first will be also replaced, so we end up with:
18 -> 0
6 -> 0
Found by clang stage2 bootstrap; testcase added.
llvm-svn: 277332
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The branch relaxation pass is computing the wrong offsets because it assumes
TLSDESC_CALLSEQ eats up 4 bytes, when in fact it is lowered to an instruction
sequence taking up 16 bytes. This can become a problem in huge files with lots
of TLS accesses, as it may slowly move branch targets out of the range computed
by the branch relaxation pass.
Fixes PR24234 https://llvm.org/bugs/show_bug.cgi?id=24234
Differential Revision: https://reviews.llvm.org/D22870
llvm-svn: 277331
|
| |
|
|
| |
llvm-svn: 277330
|
| |
|
|
|
|
| |
It looks like the two independent parts of the rotate operation (a lshr and shl) are being reordered on some bots. Add CHECK-DAGs to account for this.
llvm-svn: 277329
|
| |
|
|
|
|
| |
preventing VMOVDQU32/VMOVDQA32 from being recognized. Fix a bug in the code that stops execution dependency fix from turning operations on 32-bit integer element types into operations on 64-bit integer element types.
llvm-svn: 277327
|
| |
|
|
|
|
| |
point.
llvm-svn: 277326
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a switch is sparse and all the cases (once sorted) are in arithmetic progression, we can extract the common factor out of the switch and create a dense switch. For example:
switch (i) {
case 5: ...
case 9: ...
case 13: ...
case 17: ...
}
can become:
if ( (i - 5) % 4 ) goto default;
switch ((i - 5) / 4) {
case 0: ...
case 1: ...
case 2: ...
case 3: ...
}
or even better:
switch ( ROTR(i - 5, 2) {
case 0: ...
case 1: ...
case 2: ...
case 3: ...
}
The division and remainder operations could be costly so we only do this if the factor is a power of two, and emit a right-rotate instead of a divide/remainder sequence. Dense switches can be lowered significantly better than sparse switches and can even be transformed into lookup tables.
llvm-svn: 277325
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D19475
llvm-svn: 277323
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initialize all AArch64-specific passes in the TargetMachine so they can be run
by llc. This can lead to conflicts in opt with some command line options that
share the same name as the pass, so I took this opportunity to do some cleanups:
* rename all relevant command line options from "aarch64-blah" to
"aarch64-enable-blah" and update the tests accordingly
* run clang-format on their declarations
* move all these declarations to a common place (the TargetMachine) as opposed
to having them scattered around (AArch64BranchRelaxation and
AArch64AddressTypePromotion were the only offenders)
llvm-svn: 277322
|
| |
|
|
|
|
|
|
| |
FR32X/FR64X if AVX512 is supported and VR128X/VR256X if VLX is supported.
Had to update a stack folding test to clobber the other 16 registers since this now made them get used instead of spilling.
llvm-svn: 277321
|
| |
|
|
|
|
|
|
| |
test. The intrinsics aren't lowered to AVX512 instructions.
The intrinsics really should be removed and autoupgraded.
llvm-svn: 277320
|
| |
|
|
|
|
| |
if AVX512(for FR32X/FR64) or VLX(for VR128X/VR256) is supported. This is a minimal requirement to be able to allocate all 32 registers.
llvm-svn: 277319
|
| |
|
|
|
|
| |
getLoadStoreRegOpcode. No functional change intended.
llvm-svn: 277318
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They seem to trigger an LSan failure:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/15140/steps/check-llvm%20asan/logs/stdio
Revert "Add the tests for r277313"
This reverts commit r277314.
Revert "CodeExtractor : Add ability to preserve profile data."
This reverts commit r277313.
llvm-svn: 277317
|
| |
|
|
|
|
|
|
|
| |
No bots have yelled yet, but this test references an x86 intrinsic.
Also, it invokes llc on x86 IR.
Fixup to r277315.
llvm-svn: 277316
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function.
When extracting a set of blocks make sure to inherit all of the target
dependent attributes to make sure that the function will be valid for
lowering. One example is the "target-features" attribute for x86, if the
extracted region has functionality that relies on a specific feature it
will fail to be lowered.
This also allows for extracted functions to be valid for inlining, at
least back into the parent function, as the target attributes are tested
when inlining for compatibility.
Patch by River Riddle!
Differential Revision: https://reviews.llvm.org/D22713
llvm-svn: 277315
|
| |
|
|
|
|
| |
Forgot to `git add` them.
llvm-svn: 277314
|
| |
|
|
|
|
|
|
|
|
|
| |
Added ability to estimate the entry count of the extracted function and
the branch probabilities of the exit branches.
Patch by River Riddle!
Differential Revision: https://reviews.llvm.org/D22744
llvm-svn: 277313
|
| |
|
|
| |
llvm-svn: 277311
|
| |
|
|
| |
llvm-svn: 277310
|
| |
|
|
|
|
| |
before removing old ones
llvm-svn: 277309
|
| |
|
|
| |
llvm-svn: 277308
|
| |
|
|
|
|
| |
classes instead of manually listing individual classes.
llvm-svn: 277306
|
| |
|
|
|
|
| |
getLoadStoreRegOpcode if VLX is supported.
llvm-svn: 277305
|
| |
|
|
|
|
| |
pass and update tests.
llvm-svn: 277304
|
| |
|
|
|
|
| |
switch. No functional change intended.
llvm-svn: 277303
|
| |
|
|
|
|
| |
regular switch which already tried to handle it, but was unreachable. This has the added benefit of enabling aligned loads/stores if the stack is aligned.
llvm-svn: 277302
|
| |
|
|
| |
llvm-svn: 277301
|
| |
|
|
|
|
|
|
| |
As discussed on PR14593, this patch adds support for lowering to SHLD/SHRD from the patterns generated by DAGTypeLegalizer::ExpandShiftWithKnownAmountBit.
Differential Revision: https://reviews.llvm.org/D23000
llvm-svn: 277299
|
| |
|
|
|
|
| |
Patch by Bandzi Michal!
llvm-svn: 277298
|
| |
|
|
|
|
|
|
| |
We had import_directory_table_entry and
coff_import_directory_table_entry, remove one. Also, factor out the
logic which determins if a descriptor is a terminator.
llvm-svn: 277296
|
| |
|
|
| |
llvm-svn: 277295
|
| |
|
|
|
|
|
|
| |
those generated by ExpandShiftWithKnownAmountBit
Test for add(v,v) as well as shl(v,1)
llvm-svn: 277293
|
| |
|
|
|
|
|
|
| |
unless DQI instructions are supported. Same for ANDN, OR, and XOR.
Thanks to Igor Breger for pointing out my mistake.
llvm-svn: 277292
|
| |
|
|
|
|
| |
As discussed on D23000
llvm-svn: 277291
|
| |
|
|
| |
llvm-svn: 277290
|
| |
|
|
|
|
|
|
| |
Removed AssertZext node, which was inserted between X86ISD::SETCC and "truncate to i1".
Differential Revision: https://reviews.llvm.org/D22850
llvm-svn: 277289
|
| |
|
|
|
|
|
|
|
|
|
| |
are very handy when parsing text.
They are essentially a combination of startswith and a self-modifying
drop_front, or endswith and drop_back respectively.
Differential Revision: https://reviews.llvm.org/D22723
llvm-svn: 277288
|
| |
|
|
| |
llvm-svn: 277285
|
| |
|
|
| |
llvm-svn: 277284
|
| |
|
|
| |
llvm-svn: 277283
|
| |
|
|
| |
llvm-svn: 277282
|