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.
