[PATCH] Fix PR77826

Richard Biener rguenther@suse.de
Mon Oct 17 07:59:00 GMT 2016


On Sat, 15 Oct 2016, Marc Glisse wrote:

> 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.

Yeah, I tried to avoid any ambiguity if @@ is used and didn't like
to write (minus (plus (plus @0 @@0) @@0) @@0) (too many @@s).

> > 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)

Yes.

Richard.



More information about the Gcc-patches mailing list