Storage-Only Register Class?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Storage-Only Register Class?

Justin Holewinski-2
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Storage-Only Register Class?

Tim Northover-2
> 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.

What springs to mind is setLoadExtAction and setTruncStoreAction, if
arithmetic has to be done in a larger type anyway. I *think* LLVM
should give you a bunch of ANY_EXT loads to a legal type if you set
those properly, which you can match with whatever instructions you
want.

Or is there some oddity of your situation that means that doesn't work?

Cheers.

Tim.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Storage-Only Register Class?

Jim Grosbach
In reply to this post by Justin Holewinski-2
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 <[hidden email]> 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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Storage-Only Register Class?

Justin Holewinski-2
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.


On Thu, Aug 8, 2013 at 1:37 PM, Jim Grosbach <[hidden email]> 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 <[hidden email]> 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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




--

Thanks,

Justin Holewinski

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Storage-Only Register Class?

Tom Stellard-3
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.

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 <[hidden email]> 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 <[hidden email]>
> > 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
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
>
> --
>
> Thanks,
>
> Justin Holewinski

> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Storage-Only Register Class?

Justin Holewinski-2
On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <[hidden email]> 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.
 

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 <[hidden email]> 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 <[hidden email]>
> > 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
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
>
> --
>
> Thanks,
>
> Justin Holewinski

> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




--

Thanks,

Justin Holewinski

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Storage-Only Register Class?

Tom Stellard-3
On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote:

> On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]>
> > > > 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
> > > > > [hidden email]         http://llvm.cs.uiuc.edu
> > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Thanks,
> > >
> > > Justin Holewinski
> >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
>
> --
>
> Thanks,
>
> Justin Holewinski
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Storage-Only Register Class?

Justin Holewinski-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]>
> > > > 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
> > > > > [hidden email]         http://llvm.cs.uiuc.edu
> > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Thanks,
> > >
> > > Justin Holewinski
> >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
>
> --
>
> Thanks,
>
> Justin Holewinski



--

Thanks,

Justin Holewinski

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Storage-Only Register Class?

Justin Holewinski-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]>
> > > > 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
> > > > > [hidden email]         http://llvm.cs.uiuc.edu
> > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Thanks,
> > >
> > > Justin Holewinski
> >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
>
> --
>
> Thanks,
>
> Justin Holewinski



--

Thanks,

Justin Holewinski



--

Thanks,

Justin Holewinski

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

isd-arg-type.patch (8K) Download Attachment