[LLVMdev] ComplexPattern in child ISel nodes

[Evan Cheng]

On Jan 3, 2008, at 12:42 AM, Christopher Lamb wrote:

>
> On Jan 1, 2008, at 9:29 PM, Evan Cheng wrote:
>
>>
>> On Dec 30, 2007, at 9:04 PM, Christopher Lamb wrote:
>>
>>> Currently tablegen emits a rather surprising match code for the  
>>> following case:
>>>
>>> Suppose we have a pattern that uses a ComplexPattern to match an  
>>> operand. This pattern then appears as a child pattern in a  
>>> different pattern.
>>> Pattern 1: (N1 ComplexPattern:OP)
>>> Pattern 0: (N0 (N1 ComplexPattern:OP))
>>>
>>> The match code for ComplexPattern is passed in N1 in Pattern 1  
>>> and N0 in Pattern 0. This means that ComplexPattern is always  
>>> passed in the root of the DAG it's embedded in, rather than the  
>>> root of the DAG to which it is directly attached. I would expect  
>>> that N1 would be passed into ComplexPattern regardless of the  
>>> larger DAG in which it's embedded.
>>>
>>> Was this intended behavior, a bug, or just the way it was done?
>>
>> This is intended. I don't remember which, but I think some x86  
>> complexpattern matching code needs the root node.
>>
>>>
>>> The attached patch fundamentally changes the semantics of  
>>> ComplexPatterns to always be passed the DAG node to which the  
>>> ComplexPattern is an operand. If the current behavior is as  
>>> designed, or needed for backwards compatibility I'll try to add  
>>> an attribute to complex patterns to make this behavior optional.
>>
>> I don't see a compelling reason for making the change. Passing in  
>> the root guarantees the matching code have all the information of  
>> the expression that is being matched. It's easier for the matching  
>> code to extract the immediate enclosing node if that's desired.
>
>

Actually I take it back.  The reason for passing the enclosing node  
is so we can check (in case the complexpattern matches a load) if it  
can be folded.

Can you test your patch? If it doesn't break any tests, please commit.

Thanks,

Evan

> What's the cleanest code idiom you know for extracting the  
> immediate enclosing node? Walking up from the root testing all the  
> operands?
>
> I don't have this problem, but I don't see an obvious solution  
> using the DAG walk method:
>
> (node (node ComplexPattern:$A), OtherPattern:$A)
>
> If the operand of the ComplexPattern has multiple uses in the DAG  
> it's matching against how do you know which node is the immediate  
> enclosing node?



> --
> Christopher Lamb
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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