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

Dylan McKay via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 12 10:25:29 PDT 2015


Hello all,

I would like to propose a large change to LLVM that I would be happy to
implement.

The instruction selection legalizer knows of three different ways to
legalize an action (ignoring an already legal action).

   - Expansion
   - Promotion
   - Custom

Expanding a node will lead to one of two things - the operation will be
split into several equivalent smaller operations (i.e. 64-bit mul => two
32-bit multiplications), or it will be expanded into a different
operation(s) (i.e. SDIVREM => SDIV + SREM or a runtime library call).

This can be ambiguous - should a 128-bit SDIVREM be expanded into two
64-bit SDIVREMs or a 128-bit libcall.

It would be useful for LLVM to distinguish between these two operations -
i.e. instead of LegalizeAction::Expand, we have LegalizeAction::Expand and
LegalizeAction::Split.

   -

   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)

Full disclosure: I’m working on a backend on which the pointer type is
illegal (Atmel AVR : 8-bit microcontroller with 16-bit pointers). The
problem with the ambiguity with expand today is that LLVM implicitly
assumes that as a 16-bit register class exists, then 16-bit
addition/subtraction should exist and there is no point splitting into two
8-bit operations.

Currently we work around this by defining 16-bit pseudo instructions for
every instruction which is not properly supported. This gives us very
sub-optimal code and introduces many bugs. More detail about the problem
can be found in the old mailing list archives
<http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/087277.html>.

I’m not sure if this requires an RFC? It would be a very large breaking
change. Perhaps a less drastic solution can be found, like leaving Expand
as it is, but also adding LegalizeAction::Split which must expand only
using smaller operations.

Again, I would be happy to work on this.

Cheers,
Dylan McKay
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/ae6d69d4/attachment.html>


More information about the llvm-dev mailing list