A + B CMP A -> A CMP' CST' match.pd patterns [was [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)]
Jeff Law
law@redhat.com
Tue Jan 24 15:21:00 GMT 2017
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
More information about the Gcc-patches
mailing list