This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] simplify-rtx: Remove non-simplifying simplification (PR77729)


On Tue, Oct 3, 2017 at 12:40 AM, Jeff Law <law@redhat.com> wrote:
> On 10/02/2017 01:35 PM, Segher Boessenkool wrote:
>> If we have (X&C1)|C2 simplify_binary_operation_1 makes C1 as small as
>> possible.  This makes worse code in common cases like when the AND with
>> C1 is from a zero-extension.  This patch fixes it by removing this
>> transformation (twice).
>>
>> I tested this on 31 targets, also some variations that do the
>> transformation only for some conditions (like, do not do it if the
>> resulting constant looks "worse", e.g. has more stretches of ones).
>> 22 of those targets show no difference; 8 are best with this patch
>> variant (never do the transformation); and 64-bit hppa is not best,
>> but the difference is only four insns in a million.
>>
>> Bootstrapped and tested on powerpc64-linux {-m32,-m64}.  Is this okay
>> for trunk?  And backports?
>>
>>
>> Segher
>>
>>
>> 2017-10-02  Segher Boessenkool  <segher@kernel.crashing.org>
>>
>>       PR rtl-optimization/77729
>>       * simplify-rtx.c (simplify_binary_operation_1): Delete the (X&C1)|C2
>>       to (X&(C1&~C2))|C2 transformations.
> OK for the trunk.  I'm not sure if the BZ in question qualifies this
> patch for backporting though.  Release managers have the final say on
> the backport question.

We usually avoid doing "optimization regression" backports unless very very
important and obvious.

Richard.

> And FWIW, the PA being an outlier on an optimization question should
> never IMHO be a blocker :-)
>
> jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]