[LLVMdev] Storage-Only Register Class?

[Justin Holewinski]

It's been on the back-burner for awhile.  I'll clean it up and post it for
review soon.


On Tue, Aug 27, 2013 at 7:48 PM, Tom Stellard <tom at stellard.net> wrote:

> 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
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130829/2e4d07df/attachment.html>