[LLVMdev] ComplexPattern in child ISel nodes

[Evan Cheng]

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.

Evan

>
> --
> Christopher Lamb
>
>
> <ComplexPatternChild.patch>___________________________________________ 
> ____
> 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/20080101/2c68e59e/attachment.html>