[LLVMdev] Simpler types in TableGen isel patterns

[Francois Pichet]

On Thu, Mar 21, 2013 at 2:26 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

> Currently, instruction selection patterns are defined like this:
>
>   def : Pat<(and (not GR32:$src1), GR32:$src2),
>             (ANDN32rr GR32:$src1, GR32:$src2)>;
>   def : Pat<(and (not GR64:$src1), GR64:$src2),
>             (ANDN64rr GR64:$src1, GR64:$src2)>;
>
> TableGen infers the types of $src1 and $src2 from the specified register
> classes, and that is the only purpose of the register classes in a pattern
> like that. SelectionDAG doesn't really understand register classes, it only
> uses types.
>
> If I try to constrain the register class in a pattern, like this:
>
>   def : Pat<(and (not GR32_ABCD:$src1), GR32_ABCD:$src2),
>             (ANDN32rr GR32_ABCD:$src1, GR32_ABCD:$src2)>;
>
> I get completely ignored. SelectionDAG's InstrEmitter will still use the
> GR32 register class that was assigned to the i32 type.
>
> When using register classes as proxies for types, it also becomes very
> difficult to support more than one legal type in a register class. If I
> were to entertain the heretic notion that an f32 might fit in a 32-bit
> register:
>
>   def GR32 : RegisterClass<"X86", [i32, f32], 32, ...
>
> TableGen explodes with a thousand type inference errors.
>
>
How come the Hexagone backend is able to get away with that then?

def IntRegs : RegisterClass<"Hexagon", [i32,f32], 32,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130323/a0557183/attachment.html>