[LLVMdev] Storage-Only Register Class?

[Tom Stellard]

On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote:
> On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote:
> 
> > On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote:
> > > Good to know, thanks!
> > >
> > > Currently I'm just not declaring an i8 register class since we only have
> > > load/store/convert available for that type.  This works fine for most
> > uses,
> > > but becomes a hassle when dealing with function parameters.  For example,
> > > if the function argument is i8, the code in LowerFormalArguments sees it
> > as
> > > an i16 since that is the next target legal type.  For my target, we need
> > to
> > > load function parameters from a special memory pool; so I need to emit
> > > any-extend loads of an 8-bit memory VT to a 16-bit register VT.  But I
> > > don't see any way to get at the information that the function argument is
> > > really 8 bits unless I go back to the llvm::Function definition.  This is
> > > do-able, but feels wrong to be doing in TargetLowering.  I was trying to
> > > get around this by declaring i8 as a legal type (strictly speaking, it
> > *is*
> > > legal in the target), and relying on the legalizer to perform any
> > > extensions for me; but now it looks like it may be easier to just teach
> > > SelectionDAGBuilder to pass along the original parameter type in
> > > LowerFormalArguments and friends.
> > >
> >
> > R600 has the same issue and we just use the llvm::Function definition to
> > determine the type.  The only other alternative is to make i8 a legal
> > type, loop through all ISD opcodes and set them all to promote
> > for i8, and then fix whatever bugs you find in the SelectionDAG.
> >
> 
> We're using the same approach of inspecting the Function definition, but
> I'm trying to find a way to avoid that.  I've been trying the approach of
> declaring an i8 register class and promoting the ops, but as Jim points
> out, this currently doesn't work in SelectionDAG.  All I really need is a
> way to determine if the original type is i8, so I'm trying to thread this
> through ISD::InputArg.  Doesn't seem to be too invasive, I'm putting
> together a patch now.
> 

Hi Justin,

Were you able to finish writing this patch?  I'm working on this problem
now, and I am curious what your solution is.

Thanks,
Tom

> 
> >
> > It would be really nice if it were possible to mark a type as load/store
> > only, but I'm not sure how to begin implementing that.
> >
> > -Tom
> > >
> > > On Thu, Aug 8, 2013 at 1:37 PM, Jim Grosbach <grosbach at apple.com> wrote:
> > >
> > > > Hi Justin,
> > > >
> > > > This is a big weakness of the current SelectionDAG infrastructure.
> > There's
> > > > not a really clean way to do this. The legalizer assumes that if a
> > type is
> > > > "legal" at all, the target can do at least basic arithmetic on that
> > type.
> > > >
> > > > Theoretically, your approach of setting the operations to
> > > > "TargetLowering::Promote" for i8 should work. I think it would be
> > > > reasonable to fix SelectionDAG to allow that. It's probably a
> > non-trivial
> > > > task, though.
> > > >
> > > > -Jim
> > > >
> > > > On Aug 8, 2013, at 7:35 AM, Justin Holewinski <
> > justin.holewinski at gmail.com>
> > > > wrote:
> > > >
> > > > > Is there a way to define a register class that is storage-only?  I
> > want
> > > > to have an i8 register class that I can use for loads/stores/converts,
> > but
> > > > that does not support arithmetic.
> > > > >
> > > > > It seems addOperationAction(ISD::ADD, MVT::i8, Promote) and
> > > > SetPromotedToType(ISD::ADD, MVT::i8, MVT::i16) are not sufficient, as
> > the
> > > > legalizer just looks at whether or not the underlying type is legal
> > (which
> > > > it is).  So come instruction selection time I still have i8 adds.  Do I
> > > > need to custom handle all 8-bit arithmetic, or is there some way to
> > have
> > > > the legalizer do the promotion like it would for an illegal type?
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Justin Holewinski
> > > > > _______________________________________________
> > > > > LLVM Developers mailing list
> > > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Thanks,
> > >
> > > Justin Holewinski
> >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> 
> 
> -- 
> 
> Thanks,
> 
> Justin Holewinski