[PATCH][compare-elim] Merge zero-comparisons with normal ops

[Richard Biener]

On October 17, 2017 9:08:31 PM GMT+02:00, Michael Collison <Michael.Collison@arm.com> wrote:
>Richard and Eric,
>
>I see you have objected and indicated the additional cost. Have you
>quantified how much more expensive the pass is?

DF has known quadratic behavior in memory for certain problems. Not sure off head if DU and UD fall into this category. 

Richard. 

>-----Original Message-----
>From: Richard Biener [mailto:richard.guenther@gmail.com] 
>Sent: Tuesday, October 17, 2017 4:45 AM
>To: Eric Botcazou <ebotcazou@adacore.com>
>Cc: Jeff Law <law@redhat.com>; GCC Patches <gcc-patches@gcc.gnu.org>;
>Michael Collison <Michael.Collison@arm.com>; Segher Boessenkool
><segher@kernel.crashing.org>; Kyrill Tkachov
><kyrylo.tkachov@foss.arm.com>; nd <nd@arm.com>
>Subject: Re: [PATCH][compare-elim] Merge zero-comparisons with normal
>ops
>
>On Sat, Oct 14, 2017 at 10:39 AM, Eric Botcazou <ebotcazou@adacore.com>
>wrote:
>>> This looks good.  OK for the trunk.
>>
>> FWIW I disagree.  The patch completely shuns the existing 
>> implementation of the pass, which is based on a forward scan within 
>> basic blocks to identify the various interesting instructions and 
>> record them, and uses full-blown def-use and use-def chains instead, 
>> which are much more costly to compute.  It's not clear to me why the
>existing implementation couldn't have been extended.
>>
>> The result is that, for targets for which the pass was initially
>written, i.e.
>> targets for which most (all) arithmetic instructions clobber the 
>> flags, the pass will be slower for absolutely no benefits, as the 
>> existing implementation would already have caught all the interesting
>cases.
>>
>> So it's again a case of a generic change made for a specific target 
>> without consideration for other, admittedly less mainstream,
>targets...
>
>I agree with Eric here.
>
>Richard.
>
>> --
>> Eric Botcazou