This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: A + B CMP A -> A CMP' CST' match.pd patterns [was [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)]
On Tue, Jan 24, 2017 at 4:05 PM, Jeff Law <law@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
>
>