This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR77826


On Thu, 13 Oct 2016, Richard Biener wrote:

The patch introduces '@@' captures which do two things - first they
change the comparison used for matching back to operand_equal_p
only (thus perform "value-matching"), second the @@ capture denotes
the specific operand that should be refered to in the result
section (ifs and result expressions).

When we face (plus @0 @1) (convert? @@0) for example this is lowered
to (plus @__2 @1) (convert? @__2@0) marking the @__2 match for
value handling.

Funny, I had the opposite convention in mind ;-)

On a completely artificial example:
(minus (plus (plus @0 @@0) @@0) @0)

would correspond to:
(minus (plus (plus @1  @2)  @3) @4)

where either @1 or @4 is captured as @0, say @1 for example, @4 is compared strictly to @1, while @2 and @3 are value-compared to @1 (lax).

This way, when we talk about @0 later in the transformation, we are indeed talking about the thing that was called @0 in the input pattern, while @@0 is not-quite-@0.

But your version should be fine.

I modified the patterns you identified and the ones I did and
removed the operand_equal_p uses where possible.

Thanks. (some can be further generalized, as you explained in an earlier message, but we can do that later as the need arises)

--
Marc Glisse


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]