On 06/30/2015 01:45 AM, Richard Biener wrote:
On Mon, Jun 29, 2015 at 7:51 PM, Jeff Law <l...@redhat.com> wrote:
So do we want to restrict the new pattern on GENERIC, then rely on
phiopt to get smarter and catch this stuff for GIMPLE? Or drop the
pattern totally and do everything in phiopt on GIMPLE?
Note that IMHO it doesn't make a lot of sense to add match.pd
patterns restricted to GENERIC - those should simply go to / stay in
fold-const.c. For patterns restricted to GIMPLE match.pd is still
the proper place.
[ snip ]
So it's indeed not clear if re-writing phiopt to match.pd patterns is
possible or desirable.
Probably the thing to do is drop this match.pd change from consideration
and instead look into improving phi-opt.
I'll open a BZ to capture the missed optimization and include a link
back to this discussion.
And using operand_equal_p seems more appropriate to me (and is
still better than the original (cond @0 ...) and grubbing around
inside @0 to look at operands.
We do use operand_equal_p to query whether @0 and @0 are equal.
Ah. I had no idea. I assumed that for multiple @N references we'd just
use pointer equality. My bad.
Jeff
