llvm dev - Jul 2010 - [LLVMdev] Spilling multi-word virtual registers

On Tuesday, July 20, 2010 4:04 PM, Jakob Stoklund Olesen
>
> On Jul 20, 2010, at 10:57 AM, Ken Dyck wrote:
> 
> > Does anybody have any tips for generating spills/reloads for large
> > non-vector registers?
> > [snip]
>
>
> This is quite simple to handle. A register
> MachineOperand has a subreg field for this
> purpose. It is used to pick out subregisters
> of a virtual register.
Thanks, Jakob. That indeed was a simple fix.
> The register allocator (rewriter to be exact)
> will clear the subreg field when substituting
> the allocated physical register.
Speaking of the rewriter, I've had some problems recently where the
rewriter replaces the last of the three load instructions with a COPY
instruction because isLoadFromStackSlot() returns the same frame index
for all three load. For example,

  load a.l, <fi#n>, 0        load a.l, <fi#n>, 0
  load a.h  <fi#n>, 1  ===>  load a.h, <fi#n>, 1
  load a.e  <fi#n>, 3        move a.e, a.l

I quickly hacked around the problem by returning a frame index only for
the loads of the low sub-register (returning 0 for the rest), but I'm
sure this isn't the best solution. Is there a simple way to avoid the
replacement while still reporting the actual frame index for all of the
load instructions?

-Ken

On Jul 21, 2010, at 7:44 AM, Ken Dyck wrote:
> Speaking of the rewriter, I've had some problems recently where the
> rewriter replaces the last of the three load instructions with a COPY
> instruction because isLoadFromStackSlot() returns the same frame index
> for all three load. For example,
> 
>  load a.l, <fi#n>, 0        load a.l, <fi#n>, 0
>  load a.h  <fi#n>, 1  ===>  load a.h, <fi#n>, 1
>  load a.e  <fi#n>, 3        move a.e, a.l
> 
> I quickly hacked around the problem by returning a frame index only for
> the loads of the low sub-register (returning 0 for the rest), but I'm
> sure this isn't the best solution. Is there a simple way to avoid the
> replacement while still reporting the actual frame index for all of the
> load instructions?
Yeah, the target hooks are not really prepared for dealing with subregisters,
and the rewriter doesn't really expect multiple instructions to be inserted
by the hooks.

To be safe, you should probably only return true from isLoadFromStackSlot when
the instruction loads the whole stack slot. That is, the offset is zero, and the
stack slot size matches the register size.

If you need the rewriter to be able to undo a stack slot load/store, you will
have to create pseudo-instructions for accumulator loads and stores. Compare the
ARMExpandPseudoInsts pass.

We are working towards a design where we don't need these rewriter
shenanigans. In fact, the trivial rewriter will be used instead.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100721/88068de1/attachment.bin>

On Wednesday, July 21, 2010 11:21 AM, Jakob Stoklund Olesen
wrote:
>
> On Jul 21, 2010, at 7:44 AM, Ken Dyck wrote:
> > Speaking of the rewriter, I've had some
> problems recently where the
> > rewriter replaces the last of the three
> load instructions with a COPY
> > instruction because isLoadFromStackSlot()
> returns the same frame index
> > for all three load. For example,
> >
> >  load a.l, <fi#n>, 0        load a.l,
> <fi#n>, 0
> >  load a.h  <fi#n>, 1  ===>  load a.h,
> <fi#n>, 1
> >  load a.e  <fi#n>, 3        move a.e, a.l
> >
> > I quickly hacked around the problem by
> returning a frame index only for
> > the loads of the low sub-register
> (returning 0 for the rest), but I'm
> > sure this isn't the best solution. Is there
> a simple way to avoid the
> > replacement while still reporting the
> actual frame index for all of the
> > load instructions?
> 
> Yeah, the target hooks are not really
> prepared for dealing with subregisters, and
> the rewriter doesn't really expect multiple
> instructions to be inserted by the hooks.
> 
> To be safe, you should probably only return
> true from isLoadFromStackSlot when the
> instruction loads the whole stack slot. That
> is, the offset is zero, and the stack slot
> size matches the register size.
This seems to result in dead frame indices being passed to
eliminateFrameIndex(). I'm currently handling these by removing the
load/store instructions in which they appear. I haven't found any errors
in the code that gets generated so far, but I also notice that none of
the other back ends seem to have any special logic to handle dead slots
in eliminateFrameIndex(). Should I be concerned? 

-Ken