[LLVMdev] Simpler types in TableGen isel patterns

Jakob Stoklund Olesen stoklund at 2pi.dk
Thu Mar 21 14:38:55 PDT 2013

On Mar 21, 2013, at 1:06 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote:

> Shooting from the hip... let's say we had a predicated execution architecture which had a general integer register class and a mask register class. Both classes contain i32 as a member and the instructions that operate on those two register classes are mutually exclusive.
> A little example:
> Integer AND
> =========
> iand %i0, %i1
> Mask AND
> ========
> mand %m0, %m1
> I'm wondering if having a general pattern could cause issues there. A pattern such as this could match both register classes, leading to a bad operand in the instruction produced and an assembler error.
>   def : Pat<(and (not i32:$src1), i32:$src2),
>             (ANDN32rr i32:$src1,  i32:$src2)>;
> This shouldn't currently be an issue, but I am trying to look far down the road. Let's say that predicated execution becomes commonplace down that road and it's now more beneficial to select patterns on register classes, rather than types. 
> To be clear, this is more a thought experiment than a critique. Making your change won't impact my work and I don't feel strongly for, nor against, this change. 

The problem here is that SelectionDAG's type system doesn't always match architectures well.

Sometimes you need more fine grained distinctions than offered by the types, like in your example.

Sometimes you need something coarser than types, like when the PowerPC floating point registers can hold both f32 and f64 types. The fabs and fneg instructions are effectively polymorphic, operating on both f32 and f64 values.

Many modern architectures can perform integer arithmetic in their vector/float registers, but LLVM will always use the integer registers because of the type <-> register class mapping. This causes more cross-class copies than is necessary.

To address these problems, I think we will need to support multiple patterns matching the same primitive typed operation. The output patterns can select different instructions with different operand register classes, and we need to solve a graph coloring problem to minimize the cross-class copies produced.


More information about the llvm-dev mailing list