ComplexPattern in child ISel nodes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ComplexPattern in child ISel nodes

Christopher Lamb
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?

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.

--
Christopher Lamb




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

ComplexPatternChild.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ComplexPattern in child ISel nodes

Evan Cheng-2

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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: ComplexPattern in child ISel nodes

Christopher Lamb

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.

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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: ComplexPattern in child ISel nodes

Evan Cheng-2

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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev