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