thr3ads.net - llvm dev - [LLVMdev] Instruction pattern type inference problem [Apr 2007]

If this information is useful, please help other people find it:
Share via:

Christopher Lamb

2007-Apr-23 03:35 UTC

[LLVMdev] Instruction pattern type inference problem

I have a back end which has both scalar and vector registers that  
alias each other. I'm having a problem generating the ISel from  
tablegen that appears only when  a vector register class is declared  
to contain integer vectors. At that moment tablegen doesn't seem to  
be able to infer integer types in patterns that it was able to  
before, but I'm not clear on why that's the case.

This isn't just the results of instructions, but also immediate  
values as well. It seems to affect a smattering of node types. Any  
insights?

For instance:

where GPRegs contains types [i32, f32]

def BEQ   : IF8<Opc.BEQ,
             (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16),
             "beq $Rsrc1, $Rsrc2, $SImm16",
             [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb: 
$SImm16)], s_br>;

Tablegen reports:
BEQ:    (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32:$Rsrc2,  
SETEQ:Other), (bb:Other):$SImm16)

as soon as I add a register class that supports either [v2i32] or  
[v4i32] I get the following:

BGE:    (brcond:void (setcc:isInt GPRegs:i32:$Rsrc1, 0:i32,  
SETGE:Other), (bb:Other):$SImm16)
build/llvm/trunk/Debug/bin/tblgen: In BGE: Could not infer all types  
in pattern!

Thanks
--
Christopher Lamb

Christopher Lamb

2007-Apr-23 04:37 UTC

head link

[LLVMdev] Instruction pattern type inference problem

Digging deeper...

1. Is there a good reason that v2f32 types are excluded from the  
isFloatingPoint filter? Looks like a bug to me.

     v2f32          =  22,   //  2 x f32
     v4f32          =  23,   //  4 x f32 <== start ??
     v2f64          =  24,   //  2 x f64 <== end

   static inline bool isFloatingPoint(ValueType VT) {
     return (VT >= f32 && VT <= f128) || (VT >= v4f32
&& VT <= v2f64);
   }

2. My problem seems to stem from what appears to be under-constrained  
typing of patterns. With vectors there is a challenge because  
currently there is no type constraint available to indicate that an  
operand can/cannot be a vector type, or a constraint that operands  
must have the same number of elements (either both scalers or vectors  
with the same number of elements, but not necessarily the same  
element type or element size).

Even with these constraints, it would be difficult to apply them to  
the standard nodes in a general way, though I could be wrong. Should  
standard nodes have vector aware type constraints?

--
Christopher Lamb

On Apr 22, 2007, at 10:35 PM, Christopher Lamb wrote:
> I have a back end which has both scalar and vector registers that  
> alias each other. I'm having a problem generating the ISel from  
> tablegen that appears only when  a vector register class is  
> declared to contain integer vectors. At that moment tablegen  
> doesn't seem to be able to infer integer types in patterns that it  
> was able to before, but I'm not clear on why that's the case.
>
> This isn't just the results of instructions, but also immediate  
> values as well. It seems to affect a smattering of node types. Any  
> insights?
>
> For instance:
>
> where GPRegs contains types [i32, f32]
>
> def BEQ   : IF8<Opc.BEQ,
>             (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16),
>             "beq $Rsrc1, $Rsrc2, $SImm16",
>             [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb: 
> $SImm16)], s_br>;
>
> Tablegen reports:
> BEQ:    (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32: 
> $Rsrc2, SETEQ:Other), (bb:Other):$SImm16)
>
> as soon as I add a register class that supports either [v2i32] or  
> [v4i32] I get the following:
>
> BGE:    (brcond:void (setcc:isInt GPRegs:i32:$Rsrc1, 0:i32,  
> SETGE:Other), (bb:Other):$SImm16)
> build/llvm/trunk/Debug/bin/tblgen: In BGE: Could not infer all  
> types in pattern!
>
> Thanks
> --
> Christopher Lamb

Chris Lattner

2007-Apr-23 22:06 UTC

head link

[LLVMdev] Instruction pattern type inference problem

On Sun, 22 Apr 2007, Christopher Lamb wrote:> I have a back end which has both scalar and vector registers that
> alias each other. I'm having a problem generating the ISel from
> tablegen that appears only when  a vector register class is declared
> to contain integer vectors. At that moment tablegen doesn't seem to
> be able to infer integer types in patterns that it was able to
> before, but I'm not clear on why that's the case.
ok
> This isn't just the results of instructions, but also immediate
> values as well. It seems to affect a smattering of node types. Any
> insights?
>
> For instance:
>
> where GPRegs contains types [i32, f32]
>
> def BEQ   : IF8<Opc.BEQ,
>             (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16),
>             "beq $Rsrc1, $Rsrc2, $SImm16",
>             [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb:
> $SImm16)], s_br>;
>
> Tablegen reports:
> BEQ:    (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32:$Rsrc2,
> SETEQ:Other), (bb:Other):$SImm16)
>
> as soon as I add a register class that supports either [v2i32] or
> [v4i32] I get the following:
>
> BGE:    (brcond:void (setcc:isInt GPRegs:i32:$Rsrc1, 0:i32,
> SETGE:Other), (bb:Other):$SImm16)
> build/llvm/trunk/Debug/bin/tblgen: In BGE: Could not infer all types
> in pattern!
Comparison nodes don't support vector types.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Chris Lattner

2007-Apr-23 22:08 UTC

head link

[LLVMdev] Instruction pattern type inference problem

On Sun, 22 Apr 2007, Christopher Lamb wrote:> 1. Is there a good reason that v2f32 types are excluded from the
> isFloatingPoint filter? Looks like a bug to me.
>
>     v2f32          =  22,   //  2 x f32
>     v4f32          =  23,   //  4 x f32 <== start ??
>     v2f64          =  24,   //  2 x f64 <== end
>
>   static inline bool isFloatingPoint(ValueType VT) {
>     return (VT >= f32 && VT <= f128) || (VT >= v4f32
&& VT <= v2f64);
>   }
Definitely a bug.  I don't think any existing targets support v2f32 which 
is probably why it wasn't noticed.
> 2. My problem seems to stem from what appears to be under-constrained
> typing of patterns. With vectors there is a challenge because
> currently there is no type constraint available to indicate that an
> operand can/cannot be a vector type, or a constraint that operands
> must have the same number of elements (either both scalers or vectors
> with the same number of elements, but not necessarily the same
> element type or element size).
>
> Even with these constraints, it would be difficult to apply them to
> the standard nodes in a general way, though I could be wrong. Should
> standard nodes have vector aware type constraints?
It depends on which nodes you mean.  "and" for example, can apply to
any
integer type, including vectors.  The various compares can only apply to 
scalars, as it would be otherwise ambiguous how the comparison is done 
(i.e. is it true if all element satisfy  the predicate, or if any of 
them?)

Do you have a specific example in mind?

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Christopher Lamb

2007-Apr-23 22:54 UTC

head link

[LLVMdev] Instruction pattern type inference problem

On Apr 23, 2007, at 5:06 PM, Chris Lattner wrote:
> On Sun, 22 Apr 2007, Christopher Lamb wrote:
>> I have a back end which has both scalar and vector registers that
>> alias each other. I'm having a problem generating the ISel from
>> tablegen that appears only when  a vector register class is declared
>> to contain integer vectors. At that moment tablegen doesn't seem to
>> be able to infer integer types in patterns that it was able to
>> before, but I'm not clear on why that's the case.
>
> ok
>
>> This isn't just the results of instructions, but also immediate
>> values as well. It seems to affect a smattering of node types. Any
>> insights?
>>
>> For instance:
>>
>> where GPRegs contains types [i32, f32]
>>
>> def BEQ   : IF8<Opc.BEQ,
>>             (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16),
>>             "beq $Rsrc1, $Rsrc2, $SImm16",
>>             [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb:
>> $SImm16)], s_br>;
>>
>> Tablegen reports:
>> BEQ:    (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32:$Rsrc2,
>> SETEQ:Other), (bb:Other):$SImm16)
>>
>> as soon as I add a register class that supports either [v2i32] or
>> [v4i32] I get the following:
>>
>> BGE:    (brcond:void (setcc:isInt GPRegs:i32:$Rsrc1, 0:i32,
>> SETGE:Other), (bb:Other):$SImm16)
>> build/llvm/trunk/Debug/bin/tblgen: In BGE: Could not infer all types
>> in pattern!
>
> Comparison nodes don't support vector types.
Then this node would really benefit from a type constraint that  
indicates this. Here the type constraint 'isInt' includes all the  
integer vector types, causing tablegen to not be able to infer all  
the types in the pattern.

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070423/1117d32d/attachment.html>

Reasonably Related Threads

Search for more reasonably related threads

llvm dev - Apr 2007 - [LLVMdev] Instruction pattern type inference problem

[LLVMdev] Instruction pattern type inference problem

[LLVMdev] Instruction pattern type inference problem

[LLVMdev] Instruction pattern type inference problem

[LLVMdev] Instruction pattern type inference problem

[LLVMdev] Instruction pattern type inference problem

Reasonably Related Threads