This new version is much more aggressive about doing "full" reduction in
cases where it reduces register pressure, and also more aggressive about
rewriting induction variables to count down (or up) to zero when doing so
reduces register pressure.
It currently uses fairly simplistic algorithms for finding reuse
opportunities, but it introduces a new framework allows it to combine
multiple strategies at once to form hybrid solutions, instead of doing
all full-reduction or all base+index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94061 91177308-0d34-0410-b5e6-96231b3b80d8
of int initializers), change some methods to be static functions,
use raw_ostream::write_hex instead of a smallstring dance with
APValue::toStringUnsigned(S, 16).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93991 91177308-0d34-0410-b5e6-96231b3b80d8
GCC would put weak zero initialized mutable data in the .bss section,
we would put it into a crasy '.gnu.linkonce.b.test,"aw",@nobits'
section. Fixing this will allow simplifications next up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93844 91177308-0d34-0410-b5e6-96231b3b80d8
Instcombine does this but apparently there are situations where this pattern will escape the optimizer and / or created by isel. Here is a case that's seen in JavaScriptCore:
%t1 = sub i32 0, %a
%t2 = add i32 %t1, -1
The dag combiner pattern: ((c1-A)+c2) -> (c1+c2)-A
will fold it to -1 - %a.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93773 91177308-0d34-0410-b5e6-96231b3b80d8
For now, this pass is fairly conservative. It only perform the replacement when both the pre- and post- extension values are used in the block. It will miss cases where the post-extension values are live, but not used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93278 91177308-0d34-0410-b5e6-96231b3b80d8
has an immediate with at least 32 bits of leading zeros, to avoid needing to
materialize that immediate in a register first.
FileCheckize, tidy, and extend a testcase to cover this case.
This fixes rdar://7527390.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93160 91177308-0d34-0410-b5e6-96231b3b80d8
new AsmPrinter. This is perhaps less elegant than describing them
in terms of MOV32r0 and subreg operations, but it allows the
current register to rematerialize them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93158 91177308-0d34-0410-b5e6-96231b3b80d8
ignore alignment requirements for SIMD memory operands. This
is useful on architectures like the AMD 10h that do not trap on
unaligned references if a status bit is twiddled at startup time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93151 91177308-0d34-0410-b5e6-96231b3b80d8
R11, and then asserting that the target was in R9. Since R9 isn't reserved for
the target anymore, and is used as an argument, this patch changes the
assertion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93065 91177308-0d34-0410-b5e6-96231b3b80d8
really does need to be a vector type, because
TargetLowering::getOperationAction for SIGN_EXTEND_INREG uses that type,
and it needs to be able to distinguish between vectors and scalars.
Also, fix some more issues with legalization of vector casts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93043 91177308-0d34-0410-b5e6-96231b3b80d8
When folding a and(any_ext(load)) both the any_ext and the
load have to have only a single use.
This removes the anyext-uses.ll testcase which started failing
because it is unreduced and unclear what it is testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92950 91177308-0d34-0410-b5e6-96231b3b80d8
(OP (trunc x), (trunc y)) -> (trunc (OP x, y))
Unfortunately this simple change causes dag combine to infinite looping. The problem is the shrink demanded ops optimization tend to canonicalize expressions in the opposite manner. That is badness. This patch disable those optimizations in dag combine but instead it is done as a late pass in sdisel.
This also exposes some deficiencies in dag combine and x86 setcc / brcond lowering. Teach them to look pass ISD::TRUNCATE in various places.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92849 91177308-0d34-0410-b5e6-96231b3b80d8
(X != null) | (Y != null) --> (X|Y) != 0
(X == null) & (Y == null) --> (X|Y) == 0
so that instcombine can stop doing this for pointers. This is part of PR3351,
which is a case where instcombine doing this for pointers (inserting ptrtoint)
is pessimizing code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92406 91177308-0d34-0410-b5e6-96231b3b80d8
multiply sequence when the power is a constant integer. Before, our
codegen for std::pow(.., int) always turned into a libcall, which was
really inefficient.
This should also make many gfortran programs happier I'd imagine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92388 91177308-0d34-0410-b5e6-96231b3b80d8
compare. On other targets we end up with a call to memcmp because we don't
want 16 individual byte loads. We should be able to use movups as well, but
we're failing to select the generated icmp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92107 91177308-0d34-0410-b5e6-96231b3b80d8
SDISel. This optimization was causing simplifylibcalls to
introduce type-unsafe nastiness. This is the first step, I'll be
expanding the memcmp optimizations shortly, covering things that
we really really wouldn't want simplifylibcalls to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92098 91177308-0d34-0410-b5e6-96231b3b80d8
be non-optimal. To be precise, we should avoid folding loads if the instructions
only update part of the destination register, and the non-updated part is not
needed. e.g. cvtss2sd, sqrtss. Unfolding the load from these instructions breaks
the partial register dependency and it can improve performance. e.g.
movss (%rdi), %xmm0
cvtss2sd %xmm0, %xmm0
instead of
cvtss2sd (%rdi), %xmm0
An alternative method to break dependency is to clear the register first. e.g.
xorps %xmm0, %xmm0
cvtss2sd (%rdi), %xmm0
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91672 91177308-0d34-0410-b5e6-96231b3b80d8
This protects this test from depending on codegen not performing the
tail call optimization by default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91648 91177308-0d34-0410-b5e6-96231b3b80d8
in local register allocator. If a reg-reg copy has a phys reg
input and a virt reg output, and this is the last use of the phys
reg, assign the phys reg to the virt reg. If a reg-reg copy has
a phys reg output and we need to reload its spilled input, reload
it directly into the phys reg than passing it through another reg.
Following 76208, there is sometimes no dependency between the def of
a phys reg and its use; this creates a window where that phys reg
can be used for spilling (this is true in linear scan also). This
is bad and needs to be fixed a better way, although 76208 works too
well in practice to be reverted. However, there should normally be
no spilling within inline asm blocks. The patch here goes a long way
towards making this actually be true.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91485 91177308-0d34-0410-b5e6-96231b3b80d8
1. Only perform (zext (shl (zext x), y)) -> (shl (zext x), y) when y is a constant. This makes sure it remove at least one zest.
2. If the shift is a left shift, make sure the original shift cannot shift out bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91399 91177308-0d34-0410-b5e6-96231b3b80d8
The coalescer is supposed to clean these up, but when setting up parameters
for a function call, there may be copies to physregs. If the defining
instruction has been LICM'ed far away, the coalescer won't touch it.
The register allocation hint does not always work - when the register
allocator is backtracking, it clears the hints.
This patch takes care of a few more cases that r90163 missed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90502 91177308-0d34-0410-b5e6-96231b3b80d8
Add a testcase for the above transformation.
Fix a bogus use of APInt noticed while tracking this down.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90423 91177308-0d34-0410-b5e6-96231b3b80d8
- A valno should be set HasRedefByEC if there is an early clobber def in the middle of its live ranges. It should not be set if the def of the valno is defined by an early clobber.
- If a physical register def is tied to an use and it's an early clobber, it just means the HasRedefByEC is set since it's still one continuous live range.
- Add a couple of missing checks for HasRedefByEC in the coalescer. In general, it should not coalesce a vr with a physical register if the physical register has a early clobber def somewhere. This is overly conservative but that's the price for using such a nasty inline asm "feature".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90269 91177308-0d34-0410-b5e6-96231b3b80d8
This means that well connected blocks are copy coalesced before the less connected blocks. Connected blocks are more difficult to
coalesce because intervals are more complicated, so handling them first gives a greater chance of success.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90194 91177308-0d34-0410-b5e6-96231b3b80d8
This helps us avoid silly copies when rematting values that are copied to a physical register:
leaq _.str44(%rip), %rcx
movq %rcx, %rsi
call _strcmp
becomes:
leaq _.str44(%rip), %rsi
call _strcmp
The coalescer will not touch the movq because that would tie down the physical register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90163 91177308-0d34-0410-b5e6-96231b3b80d8
Also fixed the corresponding testcase, and the PALIGNR
intrinsic (tested for correctness with llvm-gcc).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89491 91177308-0d34-0410-b5e6-96231b3b80d8
When TwoAddressInstructionPass deletes a dead instruction, make sure that all
register kills are accounted for. The 2-addr register does not get special
treatment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89246 91177308-0d34-0410-b5e6-96231b3b80d8
The local register allocator doesn't like it when LiveVariables is run.
We should also disable edge splitting under -O0, but that has to wait a bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89125 91177308-0d34-0410-b5e6-96231b3b80d8
by the recent FixedStackPseudoSourceValue-related changes, now that
the specific bug that affected it is fixed, in r88954.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88997 91177308-0d34-0410-b5e6-96231b3b80d8
Have the asm printer emit a comment if an instruction is a spill or
reload and have the spiller mark copies it introdues so the asm printer
can also annotate those.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88911 91177308-0d34-0410-b5e6-96231b3b80d8
code-size win, and not when it's only likely to be code-size neutral,
such as when only a single instruction would be eliminated and a new
branch would be required.
This fixes rdar://7392894.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88692 91177308-0d34-0410-b5e6-96231b3b80d8
tail merging support to handle more cases.
- Recognize several cases where tail merging is beneficial even when
the tail size is smaller than the generic threshold.
- Make use of MachineInstrDesc::isBarrier to help detect
non-fallthrough blocks.
- Check for and avoid disrupting fall-through edges in more cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86871 91177308-0d34-0410-b5e6-96231b3b80d8
1. rename the movhp patfrag to movlhps, since thats what it actually matches
2. eliminate the bogus movhps load and store patterns, they were incorrect. The load transforms are already handled (correctly) by shufps/unpack.
3. revert a recent test change to its correct form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86415 91177308-0d34-0410-b5e6-96231b3b80d8
and extract_subreg as a "copy" that defines a valno.
Also fixes a typo. These two issues prevent a simple subreg coalescing from
happening before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86022 91177308-0d34-0410-b5e6-96231b3b80d8
the loop preheader. Add instructions which are already in the preheader block that
may be common expressions of those that are hoisted out. These does get a few more
instructions CSE'ed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85799 91177308-0d34-0410-b5e6-96231b3b80d8
the testcase into:
_test1: ## @test1
## BB#0: ## %entry
leaq L_test1_bb6(%rip), %rax
jmpq *%rax
L_test1_bb: ## Address Taken
LBB1_1: ## %bb
movb $1, %al
ret
L_test1_bb6: ## Address Taken
LBB1_2: ## %bb6
movb $2, %al
ret
Note, it is very very strange that BlockAddressSDNode doesn't carry
around TargetFlags. Dan, please fix this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85703 91177308-0d34-0410-b5e6-96231b3b80d8
unfolding loads for hoisting. getOpcodeAfterMemoryUnfold returns the
opcode of the original operation without the load, not the load
itself, MachineLICM needs to know the operand index in order to get
the correct register class. Extend getOpcodeAfterMemoryUnfold to
return this information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85622 91177308-0d34-0410-b5e6-96231b3b80d8
strides for now, because it doesn't handle them correctly. This fixes a
miscompile of SingleSource/Benchmarks/Misc-C++/ray.
This problem was usually hidden because indvars transforms such induction
variables into negations of canonical induction variables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85118 91177308-0d34-0410-b5e6-96231b3b80d8
bootstrapping. It's not safe to leave identity subreg_to_reg and insert_subreg
around.
- Relax register scavenging to allow use of partially "not-live" registers. It's
common for targets to operate on registers where the top bits are undef. e.g.
s0 =
d0 = insert_subreg d0<undef>, s0, 1
...
= d0
When the insert_subreg is eliminated by the coalescer, the scavenger used to
complain. The previous fix was to keep to insert_subreg around. But that's
brittle and it's overly conservative when we want to use the scavenger to
allocate registers. It's actually legal and desirable for other instructions
to use the "undef" part of d0. e.g.
s0 =
d0 = insert_subreg d0<undef>, s0, 1
...
s1 =
= s1
= d0
We probably need add a "partial-undef" marker on machine operand so the
machine verifier would not complain.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85091 91177308-0d34-0410-b5e6-96231b3b80d8
or global after a function with conflicting names. Update some testcases
that were accidentally depending on this behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85081 91177308-0d34-0410-b5e6-96231b3b80d8
to break up CFG diamonds by banishing one of the blocks to the end of
the function, which is bad for code density and branch size.
This does pessimize MultiSource/Benchmarks/Ptrdist/yacr2, the
benchmark cited as the reason for the change, however I've examined
the code and it looks more like a case of gaming a particular
branch than of being generally applicable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84803 91177308-0d34-0410-b5e6-96231b3b80d8
encounters an OEQ or UNE comparison, and update its callers to check
for this return status and recover. This fixes a problem resulting from
the LowerOperation hooks being called from LegalizeVectorOps, because
LegalizeVectorOps only lowers vectors, so OEQ and UNE comparisons may
still be at large. This fixes PR5092.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84640 91177308-0d34-0410-b5e6-96231b3b80d8
tracked. Instead of trying to manually keep track of these locations
while doing complex modifications, just recompute them when they're needed.
This fixes a bug in which the TopMBB and BotMBB were not correctly updated,
leading to invalid transformations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84598 91177308-0d34-0410-b5e6-96231b3b80d8
LLC was scheduling compares before the adds causing wrong branches to be taken
in programs, resulting in misoptimized code wherever atomic adds where used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84485 91177308-0d34-0410-b5e6-96231b3b80d8
to be more general and understand more varieties of loops.
Teach CodePlacementOpt to reorganize the basic blocks of a loop so that
they are contiguous. This also includes a fair amount of logic for preserving
fall-through edges while doing so. This fixes a BranchFolding-ism where blocks
which can't be made to use a fall-through edge and don't conveniently fit
anywhere nearby get tossed out to the end of the function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84295 91177308-0d34-0410-b5e6-96231b3b80d8
header is just the entry block to the loop, and it needn't be at
the top of the loop in the code layout.
Remove the code that suppressed loop alignment for outer loops,
so that outer loops are aligned.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84158 91177308-0d34-0410-b5e6-96231b3b80d8
it to hold the address of an sret return value, for x86-64 ABI purposes.
Also, fix the test that was originally intended to test this to actually
test it, using FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83853 91177308-0d34-0410-b5e6-96231b3b80d8
when one of the bits being tested would end up being the sign bit in the
narrower type, and a signed comparison is being performed, since this would
change the result of the signed comparison. This fixes PR5132.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83670 91177308-0d34-0410-b5e6-96231b3b80d8
verbose-asm mode, print comments instead. This eliminates a non-comment
difference between verbose-asm mode and non-verbose-asm mode.
Also, factor out the relevant code out of all the targets and into
target-independent code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83392 91177308-0d34-0410-b5e6-96231b3b80d8
physical registers. This is especially critical for the later two since they
start the live interval of a super-register. e.g.
%DO<def> = INSERT_SUBREG %D0<undef>, %S0<kill>, 1
If this instruction is eliminated, the register scavenger will not be happy as
D0 is not defined previously.
This fixes PR5055.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82968 91177308-0d34-0410-b5e6-96231b3b80d8
allows matching and remembering a string and then matching and
verifying that the string occurs later in the file.
Change X86/xor.ll to use this in some cases where the test was
checking for an arbitrary register allocation decision.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82891 91177308-0d34-0410-b5e6-96231b3b80d8
which have no defs anywhere in the function. In particular, this fixes sinking
of instructions that reference RIP on x86-64, which is currently being modeled
as a register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82815 91177308-0d34-0410-b5e6-96231b3b80d8
regex and matching it instead of trying to match chunks at a time.
Matching chunks at a time broke with check lines like
CHECK: foo {{.*}}bar
because the .* would eat the entire rest of the line and bar would
never match.
Now we just escape the fixed strings for the user, so that something
like:
CHECK: a() {{.*}}???
is matched as:
CHECK: {{a\(\) .*\?\?\?}}
transparently "under the covers".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82779 91177308-0d34-0410-b5e6-96231b3b80d8
variable increment / decrement slighter high priority.
This has major impact on some micro-benchmarks. On MultiSource/Applications
and spec tests, it's a minor win. It also reduce 256.bzip instruction count
by 8%, 55 on 164.gzip on i386 / Darwin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82485 91177308-0d34-0410-b5e6-96231b3b80d8
And fix a bug with the behavior of min/max instructions formed from
fcmp uge comparisons.
Also, use FiniteOnlyFPMath() for this code instead of UnsafeFPMath,
as it is more specific.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82466 91177308-0d34-0410-b5e6-96231b3b80d8
we pushed the beginning of the interval back 1, so the
interval would overlap with inputs that die. We were
also pushing the end of the interval back 1, though,
which means the earlyclobber didn't overlap with other
output operands. Don't do this. PR 4964.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82342 91177308-0d34-0410-b5e6-96231b3b80d8