[LLVMdev] ComplexPattern in child ISel nodes
Evan Cheng
evan.cheng at apple.com
Fri Jan 4 02:41:47 PST 2008
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>
More information about the llvm-dev
mailing list