an unconditional branch (possibly from tail merging), this code is
trying to redirect all of its predecessors to go directly to the branch
target, but that isn't feasible for indirect branches. The other
predecessors (that don't end with indirect branches) could theoretically
still be handled, but that is not easily done right now.
The AnalyzeBranch interface doesn't currently let us distinguish jump table
branches from indirect branches, and this code is currently handling
jump tables. To avoid punting on address-taken blocks, we would have to give
up handling jump tables. That seems like a bad tradeoff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85975 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
- Be consistent when referring to MachineBasicBlocks: BB#0.
- Be consistent when referring to virtual registers: %reg1024.
- Be consistent when referring to unknown physical registers: %physreg10.
- Be consistent when referring to known physical registers: %RAX
- Be consistent when referring to register 0: %reg0
- Be consistent when printing alignments: align=16
- Print jump table contents.
- Don't print host addresses, in general.
- and various other cleanups.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85682 91177308-0d34-0410-b5e6-96231b3b80d8
previously running CodePlacementOpt. Also print headers before
each dump in -print-machineinstrs mode, so that it's clear which
dump is which.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85681 91177308-0d34-0410-b5e6-96231b3b80d8
results. This works around a problem affecting targets which rely on
MVT::Flag to handle physical register defs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85638 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
bunch of associated comments, because it doesn't have anything to do
with DAGs or scheduling. This is another step in decoupling MachineInstr
emitting from scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85517 91177308-0d34-0410-b5e6-96231b3b80d8
indexed via the stack pointer, even if a frame pointer is present. Update the
heuristic to place it nearest the stack pointer in that case, rather than
nearest the frame pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85474 91177308-0d34-0410-b5e6-96231b3b80d8
the second (store) instruction in SpillSlotToUsesMap
consistently. I don't think this matters functionally,
but it's cleaner and Evan wants it this way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85463 91177308-0d34-0410-b5e6-96231b3b80d8
--- Reverse-merging r85338 into '.':
U lib/CodeGen/SimpleRegisterCoalescing.cpp
U lib/CodeGen/SimpleRegisterCoalescing.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85454 91177308-0d34-0410-b5e6-96231b3b80d8
to spill after all, we weren't handling 2-instruction
spill sequences correctly (PPC Altivec). We need to
remove the store in this case. Removing the other
instruction(s) would be goodness but is not needed for
correctness, and isn't done here. 7331562.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85437 91177308-0d34-0410-b5e6-96231b3b80d8
