llvm dev - Aug 2013 - [LLVMdev] Storage-Only Register Class?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130808/77f16e9c/attachment.html>

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

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

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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130808/1c9006f0/attachment.html>