[LLVMdev] Storage-Only Register Class?

Tue Sep 10 06:30:09 PDT 2013

Hi Tom,

Sorry for the delay.  Attached is the patch I've been using, if you still
want to take a look.

On Thu, Aug 29, 2013 at 9:28 AM, Justin Holewinski <
justin.holewinski at gmail.com> wrote:

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

-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/c341d032/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: isd-arg-type.patch
Type: application/octet-stream
Size: 6039 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/c341d032/attachment.obj>