Displaying 7 results from an estimated 7 matches for "updateterminator".
2011 May 02
2
[LLVMdev] LiveVariables not updated in MachineBasicBlock::SplitCriticalEdge?
Is LiveVariables updated correctly when TII->RemoveBranch and
TII->InsertBranch are called in the following piece of code?
- MachineBasicBlock::updateTerminator() line 307 of MachineBasicBlock.cpp:
if (FBB) {
// The block has a non-fallthrough conditional branch. If one of its
// successors is its layout successor, rewrite it to a fallthrough
// conditional branch.
if (isLayoutSuccessor(TBB)) {
if (TII->ReverseBranchCon...
2011 May 03
0
[LLVMdev] LiveVariables not updated in MachineBasicBlock::SplitCriticalEdge?
...; Alive in blocks: 5, 6, 7, 8, 10, 12, 13, 19,
> Killed by:
> #0: J <BB#17>
>
>
> As you can see, VarInfo vreg81 is killed by the unconditional jump instruction of BB#20 when it should be killed by the newly created conditional branch in BB#14 (BEQ). Is this a bug in updateTerminator() or is the back-end responsible for updating LiveVariables?
This could be a new issue. Neither ARM nor x86 have conditional branches that take live register operands, so I don't think anyone has considered if the back-end should update LiveVariables. It simply hasn't come up before.
I...
2011 May 03
1
[LLVMdev] LiveVariables not updated in MachineBasicBlock::SplitCriticalEdge?
Does updateTerminator() need to be rewritten in order to implement the
changes you suggested (call LV->replaceKillInstruction)? Or can it be taken
care of just by adding code to the files in Target/Mips?
Also, is the generated code still correct if
-disable-phi-elim-edge-splitting is added to the command line option...
2011 Oct 19
3
[LLVMdev] Question regarding basic-block placement optimization
On Tue, Oct 18, 2011 at 4:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
> On Oct 18, 2011, at 3:07 PM, Chandler Carruth wrote:
>
> On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com>wrote:
>
>> I think this should really live as a CodeGen pass. Is there any good
>> reason to make it an IR pass?
>>
>
> So, as it
2011 Oct 19
0
[LLVMdev] Question regarding basic-block placement optimization
...onditional
2. Conditional
3. Indirect.
The AnalyzeBranch() function understands the first two kinds, so if that function returns false (as in it's false that it didn't succeed) you can move the successors around, and you know that placing a successor immediately after the block and calling updateTerminator() will give you a fall-through.
If AnalyzeBranch() fails, you can still check if the last instruction in the block is an unpredicated barrier. If so, it is still safe to move the successors around, but that block will never be a fall-through. The canFallThrough() function implements this check.
I...
2011 Oct 19
3
[LLVMdev] Question regarding basic-block placement optimization
...; 3. Indirect.
>
> The AnalyzeBranch() function understands the first two kinds, so if that
> function returns false (as in it's false that it didn't succeed) you can
> move the successors around, and you know that placing a successor
> immediately after the block and calling updateTerminator() will give you a
> fall-through.
>
> If AnalyzeBranch() fails, you can still check if the last instruction in
> the block is an unpredicated barrier. If so, it is still safe to move the
> successors around, but that block will never be a fall-through. The
> canFallThrough() funct...
2011 Oct 19
0
[LLVMdev] Question regarding basic-block placement optimization
...gt;
>> The AnalyzeBranch() function understands the first two kinds, so if that
>> function returns false (as in it's false that it didn't succeed) you can
>> move the successors around, and you know that placing a successor
>> immediately after the block and calling updateTerminator() will give you a
>> fall-through.
>>
>> If AnalyzeBranch() fails, you can still check if the last instruction in
>> the block is an unpredicated barrier. If so, it is still safe to move the
>> successors around, but that block will never be a fall-through. The
>>...