Resolving branch instr with label "$BB0_-1"

Project Infrastructure LLVM Dev List Archives
1

Hello All.
On a particular target the back-end generates an instruction like:
beqz r2, “$BB0_-1”

Is it a back-end specific issue? Could someone please help me figure out how this gets resolved? What confuses me is, all other branches are correctly labelled and resolved!

Thanks.
Girish.

2

May be you have branched to a BB which has been deleted.

3

Hi Aries.
Thanks very much!

Precisely this is the situation! There’re two consecutive branches (br1cond and br2uncond). Inside of AnalyzeBranch, there’s an opcode swap of br2uncond (ex. j_foward to j_backward). There I do BuildMI (newOpcode) and followed by br2uncond->eraseFromParent(). This results in br1cond loosing it’s label/offset. How could I resolve this?

Best regards,
Girish.

4

Precisely this is the situation! There're two consecutive branches (br1cond
and br2uncond). Inside of AnalyzeBranch, there's an opcode swap of br2uncond
(ex. j_foward to j_backward). There I do BuildMI (newOpcode) and followed by
br2uncond->eraseFromParent(). This results in br1cond loosing it's
label/offset. How could I resolve this?

Your code is broken. AnalyzeBranch should not modify anything.

5

Hello Anton.
Thanks for the comment.

6

br2uncond->eraseFromParent(). This results in br1cond loosing it's
label/offset. How could I resolve this?

Your code is broken. AnalyzeBranch should not modify anything.

I was taking a clue from Mips/MipsInstrInfo.cpp: AnalyzeBranch :frowning:
Could you please suggest appropriate alternative place for such a
modification?

Ah sorry, my memory served me wrong. You can modify the stuff there,
but very careful :slight_smile:
It's hard to tell w/o seeing the actual code. But I don't see how
inserting new instruction inside MBB might invalidate the BB
destinations of other stuff.

If you're doing more complex stuff (e.g. insert / remove BBs), then
you should carefully update all possible references.

7

Hi girish,

You can reference scalar transformation code under lib/Transforms/Scalar for some hints, such as LoopDeletion.cpp.
As your transformation may cause CFG be changed, you should make sure you are not “AU.setPreservesCFG()”.