llvm dev - Aug 2015 - Splitting 'expand' into 'split' and `expand`.

Are you primarily trying to avoid Expand being implemented as a lib call
with a larger type?

No - I’m stuck in this situation:

   - 8-bit addition is legal
   - 16-bit addition is illegal, should expand into an add and an add with
   carry
   - A few operations support 16-bit operands - the 16-bit DREGS register
   class

The legalizer sees that 16-bit addition should expand. It sees that there
is a 16-bit register class,
and it sees that 16-bit values are legal. As 16-bit is legal, it does not
try and expand into a smaller type (8-bit).

This causes instruction selection to fail.

I can see why you’d want ExpandLibCall to be a separate action. Our
overhanging problem is that
the legalizer only gives very coarse-grained control over the way it
legalizes values.
​

On Thu, Aug 13, 2015 at 2:14 PM, Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
> On Aug 12, 2015, at 10:25 AM, Dylan McKay via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>    - Expand should always expand the node into a different pattern (such
>    as MULHU expanding to MUL and a copy of the top half).
>    - Split will always split an operation into several smaller,
>    operations (such as 128-bit addition being split into a 64-bit addition
and
>    a 64-bit addition with carry)
>
>
> Are you primarily trying to avoid Expand being implemented as a lib call
> with a larger type? Are there other cases where you want to avoid a
> different type of expansion besides a call? Before I’ve wanted to have
> ExpandLibcall be a separate action from Expand, which is somewhat similar
> idea.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/626bc911/attachment.html>

> On Aug 12, 2015, at 8:36 PM, Dylan McKay <dylanmckay34 at gmail.com>
wrote:
> 
> 16-bit addition is illegal, should expand into an add and an add with carry
> A few operations support 16-bit operands - the 16-bit DREGS register class
This sounds like basically the same situation AMDGPU has with 64-bit integers.
Since you have a 16-bit register class, you avoid terrible problems by not
having i16 be a legal type. There is no 64-bit add, and needs to be expanded
into 32-bit add + carry. There are fewer 64-bit operations available, but some
are. It’s faked by saying 64-bit add is legal and the expand to add + carry is
handled during instruction selection, which works and also makes addressing mode
matching easier.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150812/0ca16cf0/attachment.html>

It’s faked by saying 64-bit add is legal and the expand to add + carry is
handled during instruction selection, which works and also makes addressing
mode matching easier.

This is basically what we do currently. So this proposal (or at least
something similar) would also help the AMDGPU backend?
​

On Thu, Aug 13, 2015 at 4:21 PM, Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
> On Aug 12, 2015, at 8:36 PM, Dylan McKay <dylanmckay34 at gmail.com>
wrote:
>
>
>    - 16-bit addition is illegal, should expand into an add and an add
>    with carry
>    - A few operations support 16-bit operands - the 16-bit DREGS register
>    class
>
> This sounds like basically the same situation AMDGPU has with 64-bit
> integers. Since you have a 16-bit register class, you avoid terrible
> problems by not having i16 be a legal type. There is no 64-bit add, and
> needs to be expanded into 32-bit add + carry. There are fewer 64-bit
> operations available, but some are. It’s faked by saying 64-bit add is
> legal and the expand to add + carry is handled during instruction
> selection, which works and also makes addressing mode matching easier.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/ae75d3d7/attachment.html>