[llvm-dev] Splitting 'expand' into 'split' and `expand`.
Dylan McKay via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 12 20:36:05 PDT 2015
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
- A few operations support 16-bit operands - the 16-bit DREGS register
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev