While adding support for branch instructions in my backend, I run into a
trouble. The code to handle branches looks like:
void visitBranchInst(BranchInst& BI)
{
BB->addSuccessor (MBBMap[BI.getSuccessor(0)]);
if (BI.isConditional())
BB->addSuccessor (MBBMap[BI.getSuccessor(1)]);
...........
BuildMI(BB, NM::GOTO, 1).addPCDisp(BI.getSuccessor(0));
BuildMI(BB, NM::GOTO, 1).addPCDisp(BI.getSuccessor(1));
}
The machine code after instruction selection is:
entry (0x8681458):
%reg1024 = load <fi#-1>
%reg1025 = load <fi#-2>
setcc %reg1024, %reg1025
goto %disp(label then)
goto %disp(label else)
then (0x8681688):
%reg1026 = + %reg1025, %reg1024
%gr7 = move %reg1026
return
....
which looks ok, but after register allocation and prolog/epilogue insertion, I
get this:
entry (0x8681458):
.....
setcc %gr0, %gr1
goto %disp(label then)
goto %disp(label else)
%ar6 = + %ar6, 1
store %ar6, %gr0
%ar6 = - %ar6, 1
%ar6 = + %ar6, 2
store %ar6, %gr1
%ar6 = - %ar6, 2
The code after "goto" is disturbing. It looks like spill code, but
it's not
going to be ever executed. Any ideas why it's generated? Is there any
additional information I should provide?
- Volodya
On Tue, 8 Jun 2004, Vladimir Prus wrote:> While adding support for branch instructions in my backend, I run into a > trouble. The code to handle branches looks like: > The machine code after instruction selection is: > > entry (0x8681458): > %reg1024 = load <fi#-1> > %reg1025 = load <fi#-2> > setcc %reg1024, %reg1025 > goto %disp(label then) > goto %disp(label else)I assume that the two unconditional gotos are just test code, right? If not, the second one is dead.> which looks ok, but after register allocation and prolog/epilogue insertion, I > get this: > > entry (0x8681458): > ..... > setcc %gr0, %gr1 > goto %disp(label then) > goto %disp(label else) > %ar6 = + %ar6, 1 > store %ar6, %gr0 > %ar6 = - %ar6, 1 > %ar6 = + %ar6, 2 > store %ar6, %gr1 > %ar6 = - %ar6, 2 > > The code after "goto" is disturbing. It looks like spill code, but it's not > going to be ever executed. Any ideas why it's generated? Is there any > additional information I should provide?Yup, just add the "isTerminator" bit on your gotos in your tablegen description for the instruction. This informs the code generator that any spill code has to go above the instructions. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
Chris Lattner wrote:> On Tue, 8 Jun 2004, Vladimir Prus wrote: > > While adding support for branch instructions in my backend, I run into a > > trouble. The code to handle branches looks like: > > The machine code after instruction selection is: > > > > entry (0x8681458): > > %reg1024 = load <fi#-1> > > %reg1025 = load <fi#-2> > > setcc %reg1024, %reg1025 > > goto %disp(label then) > > goto %disp(label else) > > I assume that the two unconditional gotos are just test code, right? If > not, the second one is dead.Yes, in the final form there will be "iflt" instruction before the first goto, making it conditional.> > The code after "goto" is disturbing. It looks like spill code, but it's > > not going to be ever executed. Any ideas why it's generated? Is there any > > additional information I should provide? > > Yup, just add the "isTerminator" bit on your gotos in your tablegen > description for the instruction. This informs the code generator that any > spill code has to go above the instructions.Thanks, this works! I don't yet understand why spill code is needed there at all, but I'll return to that when I have branches working correctly. - Volodya