llvm dev - Jan 2008 - [LLVMdev] specifying accumulator based load/stores

I have load / store instructions that require accumulator.
So a store looks like..

   mov 3, acc
   st acc, addr

I have specified "acc" as a separate register class containing only
one
register which is the "acc".
The instr patterns are then splitted into:

   set imm:$src, ACCClass:$dst  (generating the "mov" above)
   set ACCClass:$src, mem:$dst  (generating the "st" above)


The problem with the generated code is incorrectly assuming that value in
"acc" is still live.
for example, for code like below

   a = 3;
   b = 4;
   c = 3;


it generates:

  mov 3, acc
  st  acc, @a
  mov 4, acc
  st acc, @b
  st acc, @c    (Wrong)


When I use the GPRRegs, which has more regs, the code is ok.
is it because I still haven't implemented the stack/frame related routines
and the value in acc is getting spilled to stack and reloaded?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080117/6285d8b0/attachment.html>

On Jan 17, 2008, at 4:12 AM, Sanjiv Gupta wrote:
> I have load / store instructions that require accumulator.
> So a store looks like..
>
>    mov 3, acc
>    st acc, addr
>
> I have specified "acc" as a separate register class containing
only
> one register which is the "acc".
> The instr patterns are then splitted into:
>
>    set imm:$src, ACCClass:$dst  (generating the "mov" above)
>    set ACCClass:$src, mem:$dst  (generating the "st" above)
>
>
> The problem with the generated code is incorrectly assuming that  
> value in "acc" is still live.
> for example, for code like below
>
>    a = 3;
>    b = 4;
>    c = 3;
>
>
> it generates:
>
>   mov 3, acc
>   st  acc, @a
>   mov 4, acc
>   st acc, @b
>   st acc, @c    (Wrong)
>
>
> When I use the GPRRegs, which has more regs, the code is ok.
> is it because I still haven't implemented the stack/frame related  
> routines and the value in acc is getting spilled to stack and  
> reloaded?
It's very hard to tell what's going on without having access to your  
backend. If you dump out the machineinstrs just before register  
allocation and again after allocation but before spiller rewrite  
(VirtRegMap.cpp), it might be easier to see where things started going  
wrong.

Evan
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Thanks Evan.
I checked into and found that it is spilling the "acc" to stack slot
and
reloading it later.
How do I tell it to rematerialize constants into "acc" rather than to
spill
/ reload the "acc".


Thanks,
sanjiv

On 1/18/08, Evan Cheng <evan.cheng at apple.com>
wrote:
>
>
> On Jan 17, 2008, at 4:12 AM, Sanjiv Gupta wrote:
>
> > I have load / store instructions that require accumulator.
> > So a store looks like..
> >
> >    mov 3, acc
> >    st acc, addr
> >
> > I have specified "acc" as a separate register class
containing only
> > one register which is the "acc".
> > The instr patterns are then splitted into:
> >
> >    set imm:$src, ACCClass:$dst  (generating the "mov" above)
> >    set ACCClass:$src, mem:$dst  (generating the "st" above)
> >
> >
> > The problem with the generated code is incorrectly assuming that
> > value in "acc" is still live.
> > for example, for code like below
> >
> >    a = 3;
> >    b = 4;
> >    c = 3;
> >
> >
> > it generates:
> >
> >   mov 3, acc
> >   st  acc, @a
> >   mov 4, acc
> >   st acc, @b
> >   st acc, @c    (Wrong)
> >
> >
> > When I use the GPRRegs, which has more regs, the code is ok.
> > is it because I still haven't implemented the stack/frame related
> > routines and the value in acc is getting spilled to stack and
> > reloaded?
>
> It's very hard to tell what's going on without having access to
your
> backend. If you dump out the machineinstrs just before register
> allocation and again after allocation but before spiller rewrite
> (VirtRegMap.cpp), it might be easier to see where things started going
> wrong.
>
> Evan
>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080118/811ed456/attachment.html>