On Tue, Oct 3, 2017 at 12:40 AM, Jeff Law <l...@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 <seg...@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
