The bundle_iterator::operator++ function now doesn't need to dig out the
basic block and check against end(). It can use the isBundledWithSucc()
flag to find the last bundled instruction safely.
Similarly, MachineInstr::isBundled() no longer needs to look at
iterators etc. It only has to look at flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170473 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the instr_iterator versions of the splice() functions. It doesn't
seem useful to be able to splice sequences of instructions that don't
consist of full bundles.
The normal splice functions that take MBB::iterator arguments are not
changed, and they can move whole bundles around without any problems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170456 91177308-0d34-0410-b5e6-96231b3b80d8
The normal insert() function takes an MBB::iterator position, and
inserts a stand-alone MachineInstr as before.
The insert() function that takes an MBB::instr_iterator position can
insert instructions inside a bundle, and will now update the bundle
flags correctly when that happens.
When the insert position is between two bundles, it is unclear whether
the instruction should be appended to the previous bundle, prepended to
the next bundle, or stand on its own. The MBB::insert() function doesn't
bundle the instruction in that case, use the MIBundleBuilder class for
that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170437 91177308-0d34-0410-b5e6-96231b3b80d8
Most code is oblivious to bundles and uses the MBB::iterator which only
visits whole bundles. MBB::erase() operates on whole bundles at a time
as before.
MBB::remove() now refuses to remove bundled instructions. It is not safe
to remove all instructions in a bundle without deleting them since there
is no way of returning pointers to all the removed instructions.
MBB::remove_instr() and MBB::erase_instr() will now update bundle flags
correctly, lifting individual instructions out of bundles while leaving
the remaining bundle intact.
The MachineInstr convenience functions are updated so
eraseFromParent() erases a whole bundle as before
eraseFromBundle() erases a single instruction, leaving the rest of its bundle.
removeFromParent() refuses to operate on bundled instructions, and
removeFromBundle() lifts a single instruction out of its bundle.
These functions will no longer accidentally split or coalesce bundles -
bundle flags are updated to preserve the existing bundling, and explicit
bundleWith* / unbundleFrom* functions should be used to change the
instruction bundling.
This API update is still a work in progress. I am going to update APIs
first so they maintain bundle flags automatically when possible. Then
I'll add stricter verification of the bundle flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170384 91177308-0d34-0410-b5e6-96231b3b80d8
AKA: Recompile *ALL* the source code!
This one went much better. No manual edits here. I spot-checked for
silliness and grep-checked for really broken edits and everything seemed
good. It all still compiles. Yell if you see something that looks goofy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169133 91177308-0d34-0410-b5e6-96231b3b80d8
The search for liveness is clipped to a specific number of instructions around the target MachineInstr, in order to avoid degenerating into an O(N^2) algorithm. It tries to use various clues about how instructions around (both before and after) a given MachineInstr use that register, to determine its state at the MachineInstr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163695 91177308-0d34-0410-b5e6-96231b3b80d8
The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.
This patch was originally committed as r161460, but reverted again
because of assertion failures. Now that duplicate Machine CFG edges have
been eliminated, this works properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162233 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM IR has labeled duplicate CFG edges, but since Machine CFG edges
don't have labels, it doesn't make sense to allow duplicates. There is
no way of telling what the edges mean.
Duplicate CFG edges cause confusion when dealing with edge weights. It
seems that code producing duplicate CFG edges usually does the wrong
thing with edge weights.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162227 91177308-0d34-0410-b5e6-96231b3b80d8
The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161460 91177308-0d34-0410-b5e6-96231b3b80d8
A->isPredecessor(B) is the same as B->isSuccessor(A), but it can
tolerate a B that is null or dangling. This shouldn't happen normally,
but it it useful for verification code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160968 91177308-0d34-0410-b5e6-96231b3b80d8
This showed up the first time rend() was called on a bundled instruction
in the Mips backend.
Also avoid dereferencing end() in bundle_iterator::operator++().
We still don't have a place to put unit tests for this stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158310 91177308-0d34-0410-b5e6-96231b3b80d8
Extract a base class and provide four specific sub-classes for iterating
over const/non-const bundles/instructions.
This eliminates the mystery bool constructor argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151684 91177308-0d34-0410-b5e6-96231b3b80d8
The MIOperands iterator can visit operands on a single instruction, or
all operands in a bundle. This simplifies code like the register
allocator that treats bundles as a set of operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151529 91177308-0d34-0410-b5e6-96231b3b80d8
to finalize MI bundles (i.e. add BUNDLE instruction and computing register def
and use lists of the BUNDLE instruction) and a pass to unpack bundles.
- Teach more of MachineBasic and MachineInstr methods to be bundle aware.
- Switch Thumb2 IT block to MI bundles and delete the hazard recognizer hack to
prevent IT blocks from being broken apart.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146542 91177308-0d34-0410-b5e6-96231b3b80d8
1. Added opcode BUNDLE
2. Taught MachineInstr class to deal with bundled MIs
3. Changed MachineBasicBlock iterator to skip over bundled MIs; added an iterator to walk all the MIs
4. Taught MachineBasicBlock methods about bundled MIs
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145975 91177308-0d34-0410-b5e6-96231b3b80d8
This was actually a bit of a mess. TLI.setPrefLoopAlignment was clearly
documented as taking log2(bytes) units, but the x86 target would still
set a preferred loop alignment of '16'.
CodePlacementOpt passed this number on to the basic block, and
AsmPrinter interpreted it as bytes.
Now both MachineFunction and MachineBasicBlock use logarithmic
alignments.
Obviously, MachineConstantPool still measures alignments in bytes, so we
can emulate the thrill of using as.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145889 91177308-0d34-0410-b5e6-96231b3b80d8
BranchProbabilityInfo (expect setEdgeWeight which is not available here).
Branch Weights are kept in MachineBasicBlocks. To turn off this analysis
set -use-mbpi=false.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133184 91177308-0d34-0410-b5e6-96231b3b80d8
inlined path for the common case.
Most basic blocks don't contain a call that may throw, so the last split point
os simply the first terminator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128874 91177308-0d34-0410-b5e6-96231b3b80d8
Correctly terminate the range of register DBG_VALUEs when the register is
clobbered or when the basic block ends.
The code is now ready to deal with variables that are sometimes in a register
and sometimes on the stack. We just need to teach emitDebugLoc to say 'stack
slot'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128327 91177308-0d34-0410-b5e6-96231b3b80d8
A live range cannot be split everywhere in a basic block. A split must go before
the first terminator, and if the variable is live into a landing pad, the split
must happen before the call that can throw.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124894 91177308-0d34-0410-b5e6-96231b3b80d8
into a utility routine, teach it how to update MachineLoopInfo, and
make use of it in MachineLICM to split critical edges on demand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106555 91177308-0d34-0410-b5e6-96231b3b80d8
MachineBasicBlock::livein_iterator a const_iterator, because
clients shouldn't ever be using the iterator interface to
mutate the livein set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101147 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
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
