On 01/24/2017 07:29 AM, Marc Glisse wrote:
On Tue, 24 Jan 2017, Richard Biener wrote:
That was my thought as well, but AFAICT we only call into match.pd
from VRP if we changed the insn.
Yes - there was thoughts to change that (but it comes at an expense).
Basically we'd like to re-fold stmts that indirectly use stmts we
changed. We certainly don't want to re-fold everything all the time.
VRP is kind of a special case, every variable for which it finds a
new/improved range could be considered changed, since it may trigger
some extra transformation in match.pd (same for CCP and the nonzero
mask).
But that would assume that match.pd is relying on range information and
could thus use the improved range information. *If* match.pd is using
the range information generated by VRP, it's not terribly pervasive.
But waiting until forwprop3 means we're leaving a ton of useless blocks
and statements in the IL for this testcase, and likely other code using
std::vec.
Perhaps rather than open-coding a fix in VRP I could have VRP call into
match.pd slightly more aggressively (say just for gimple_cond). That
may be enough to capture the effects much earlier in the pipeline
without trying to fold *everything*.
Jeff
