Displaying 5 results from an estimated 5 matches for "bundledpred".
2017 Dec 19
3
DBG_VALUE insertion for spills breaks bundles
...lls does not seem to be handling insert locations inside bundles well. If the spill instruction is part of a bundle, the new DBG_VALUE is inserted after it, but does not have the bundling flags set. This essentially means that if we start with a set of bundled instructions:
MI1 [BundledSucc=true, BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]
Where MI1 is a spill, and MI2 is a different instruction, after ExtendRanges we end up with
MI1 [BundledSucc=true, BundledPred=false]
DBG_VALUE MI [BundledSucc=false, BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]
Since this happen...
2017 Dec 22
0
DBG_VALUE insertion for spills breaks bundles
...lls does not seem to be handling insert locations inside bundles well. If the spill instruction is part of a bundle, the new DBG_VALUE is inserted after it, but does not have the bundling flags set. This essentially means that if we start with a set of bundled instructions:
MI1 [BundledSucc=true, BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]
Where MI1 is a spill, and MI2 is a different instruction, after ExtendRanges we end up with
MI1 [BundledSucc=true, BundledPred=false]
DBG_VALUE MI [BundledSucc=false, BundledPred=false]
MI2 [BundledSucc=false, BundledPred=true]
Since this happen...
2013 Feb 01
4
[LLVMdev] Asserts in bundleWithPred() and bundleWithSucc()
...t removing them rather than adding new
methods?... or do you have a better suggestion?
Thanks.
Sergei
void MachineInstr::bundleWithPred() {
assert(!isBundledWithPred() && "MI is already bundled with its
predecessor"); <<<<<<<<<<<<
setFlag(BundledPred);
MachineBasicBlock::instr_iterator Pred = this;
--Pred;
assert(!Pred->isBundledWithSucc() && "Inconsistent bundle flags");
<<<<<<<<<<<<<
Pred->setFlag(BundledSucc);
}
void MachineInstr::bundleWithSucc() {
assert(!isBundledWi...
2013 Feb 02
0
[LLVMdev] Asserts in bundleWithPred() and bundleWithSucc()
On Feb 1, 2013, at 3:43 PM, "Sergei Larin" <slarin at codeaurora.org> wrote:
> I have a question about the following (four) asserts recently added in
> bundleWithPred() and bundleWithSucc() (see below). What is the real danger
> of reasserting a connection even if it already exist?
The intention was to identify code that may have been converted from the old style a
2013 Feb 04
2
[LLVMdev] Asserts in bundleWithPred() and bundleWithSucc()
...or"); <<<<<<<<<<<<<<<<<<<<<<<<
setFlag(BundledSucc);
MachineBasicBlock::instr_iterator Succ = this;
++Succ;
assert(!Succ->isBundledWithPred() && "Inconsistent bundle flags");
Succ->setFlag(BundledPred);
}
Here is the call stack:
#3 ... in llvm::MachineInstr::bundleWithSucc (this=0x4c6aa20) at
...lib/CodeGen/MachineInstr.cpp:882
#4 ... in llvm::MIBundleBuilder::insert (this=0x7fffffff7dc0, I=...,
MI=0x4c6aa20) at ...include/llvm/CodeGen/MachineInstrBuilder.h:417
#5 ... in llvm::MIBundleBuil...