[llvm-dev] Splitting 'expand' into 'split' and `expand`.

[Dylan McKay via llvm-dev]

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>