The change in SelectionDAGBuilder is needed to allow using bitcasts to convert
between f64 (the default type for ARM "d" registers) and 64-bit Neon vector
types. Radar 7457110.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91649 91177308-0d34-0410-b5e6-96231b3b80d8
non-landing pad basic block as the successor to a block that ends in an
unconditional jump will cause block folding to remove the added block as a
successor. Thus eventually removing it AND the landing pad entirely. Critical
edge splitting is an optimization, so we can safely turn it off when dealing
with landing pads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91634 91177308-0d34-0410-b5e6-96231b3b80d8
LegalizeDAG.cpp. Unlike the code it replaces, which simply decrements the simple
type by one, getHalfSizedIntegerVT() searches for the smallest simple integer
type that is at least half the size of the type it is called on. This approach
has the advantage that it will continue working if a new value type (such as
i24) is added to MVT.
Also, in preparation for new value types, remove the assertions that
non-power-of-2 8-bit-mutiple types are Extended when legalizing extload and
truncstore operations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91614 91177308-0d34-0410-b5e6-96231b3b80d8
Fold (zext (and x, cst)) -> (and (zext x), cst)
DAG combiner likes to optimize expression in the other way so this would end up cause an infinite looping.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91574 91177308-0d34-0410-b5e6-96231b3b80d8
Tail duplication produces lots of identical phi nodes in different basic
blocks. Teach PHIElimination to reuse the join registers when lowering a phi
node that is identical to an already lowered node. This saves virtual
registers, and more importantly it avoids creating copies the the coalescer
doesn't know how to eliminate.
Teach LiveIntervalAnalysis about the phi joins with multiple uses.
This patch significantly reduces code size produced by -pre-regalloc-taildup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91549 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
isPodLike type trait. This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91421 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
stuff isn't used just yet.
We want to model the GCC `-fno-schedule-insns' and `-fno-schedule-insns2'
flags. The hypothesis is that the people who use these flags know what they are
doing, and have hand-optimized the C code to reduce latencies and other
conflicts.
The idea behind our scheme to turn off scheduling is to create a map "on the
side" during DAG generation. It will order the nodes by how they appeared in the
code. This map is then used during scheduling to get the ordering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91392 91177308-0d34-0410-b5e6-96231b3b80d8
branches only to a landing pad. Without this check, the compiler would go into
an infinite loop because the branch to a landing pad is an "abnormal" edge which
wasn't being taken into account.
This is the meat of that fix:
if (!PrevBB.canFallThrough() && !MBB->BranchesToLandingPad(MBB)) {
The other stuff is simplification of the "branches to a landing pad" code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91161 91177308-0d34-0410-b5e6-96231b3b80d8
- Loosen the restrictions when checking of it branches to a landing pad.
- Make the loop more efficient by checking the '.insert' return value.
- Do cheaper checks first.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91101 91177308-0d34-0410-b5e6-96231b3b80d8
more than one successor. Normally, these extra successors are dead. However,
some of them may branch to exception handling landing pads. If we remove those
successors, then the landing pads could go away if all predecessors to it are
removed. Before, it was checking if the direct successor was the landing
pad. But it could be the result of jumping through multiple basic blocks to get
to it. If we were to only check for the existence of an EH_LABEL in the basic
block and not remove successors if it's in there, then it could stop actually
dead basic blocks from being removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91092 91177308-0d34-0410-b5e6-96231b3b80d8
Create global variable DIEs after creating subprogram DIEs. This allows function level static variable's to find their context at the time of DIE creation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91055 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 is more conservative than r90502, and does not break
483.xalancbmk/i686. It still breaks the PowerPC bootstrap, so it is disabled
by default, and can be enabled with the -trivial-coalesce-ends option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91049 91177308-0d34-0410-b5e6-96231b3b80d8
When a call is placed to spill an interval this spiller will first try to
break the interval up into its component values. Single value intervals and
intervals which have already been split (or are the result of previous splits)
are spilled by the default spiller.
Splitting intervals as described above may improve the performance of generated
code in some circumstances. This work is experimental however, and it still
miscompiles many benchmarks. It's not recommended for general use yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90951 91177308-0d34-0410-b5e6-96231b3b80d8
and that Instruction only. Implement this by setting the "current debug position"
back to Unknown after processing each instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90632 91177308-0d34-0410-b5e6-96231b3b80d8
Don't print "SrcLine"; just print the filename and line number, which
is obvious enough and more informative.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90631 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
Pointed out by Javier Martinez (who also provided a patch). Since
this logic is not used on (for example) x86, I guess nobody noticed.
Tested by generating SHL, SRL, SRA on various choices of i64 for all
possible shift amounts, and comparing with gcc. Since I did this on
x86-32, I had to force the use of ExpandShiftWithUnknownAmountBit.
What I'm saying here is that I don't have a testcase I can add to the
repository.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90482 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
The MO reference to a MachineOperand can be invalidated by
MachineInstr::addOperand. Don't even use it for debugging.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90381 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
We want LiveVariables clients to use methods rather than accessing the
getVarInfo data structure directly. That way it will be possible to change the
LiveVariables representation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90240 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
branches even when optimizing for code size. Unless we find evidence to the
contrary in the future, the special treatment for indirect branches does not
have a significant effect on code size, and performance still matters with -Os.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90147 91177308-0d34-0410-b5e6-96231b3b80d8
for all the processors where I have tried it, and even when it might not help
performance, the cost is quite low. The opportunities for duplicating
indirect branches are limited by other factors so code size does not change
much due to tail duplicating indirect branches aggressively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90144 91177308-0d34-0410-b5e6-96231b3b80d8
divide/remainder since these operations can trap by unroll them and adding undefs
for the resulting vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90108 91177308-0d34-0410-b5e6-96231b3b80d8
running tail duplication when doing branch folding for if-conversion, and
we also want to be able to run tail duplication earlier to fix some
reg alloc problems. Move the CanFallThrough function from BranchFolding
to MachineBasicBlock so that it can be shared by TailDuplication.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89904 91177308-0d34-0410-b5e6-96231b3b80d8
Make tail duplication of indirect branches much more aggressive (for targets
that indicate that it is profitable), based on further experience with
this transformation. I compiled 3 large applications with and without
this more aggressive tail duplication and measured minimal changes in code
size. ("size" on Darwin seems to round the text size up to the nearest
page boundary, so I can only say that any code size increase was less than
one 4k page.) Radar 7421267.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89814 91177308-0d34-0410-b5e6-96231b3b80d8
Note that "hasDotLocAndDotFile"-style debug info was already broken;
people wanting this functionality should implement it in the
AsmPrinter/DwarfWriter code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89711 91177308-0d34-0410-b5e6-96231b3b80d8
of SelectionDAGBuild.h/cpp into its own files, to help separate
general lowering logic from SelectionDAG-specific lowering logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89667 91177308-0d34-0410-b5e6-96231b3b80d8
tell debug info which base register to use to reference a frame index on a
per-index basis. This is useful, for example, in the presence of dynamic
stack realignment when local variables are indexed via the stack pointer and
stack-based arguments via the frame pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89620 91177308-0d34-0410-b5e6-96231b3b80d8