On Tue, Jan 24, 2017 at 4:05 PM, Jeff Law <l...@redhat.com> wrote: > 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*.
Sure, the only disadvantage of doing it in VRP (in vrp_fold_stmt) is that you may end up doing it twice. Richard. > Jeff > >
