This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: match.pd handling of three-constant bitops
Richard Biener <richard.guenther@gmail.com> writes:
> On Wed, Sep 20, 2017 at 2:18 PM, Richard Sandiford
> <richard.sandiford@linaro.org> wrote:
>> natch.pd tries to reassociate two bit operations if both of them have
>> constant operands. However, with the polynomial integers added later,
>> there's no guarantee that a bit operation on two integers can be folded
>> at compile time. This means that the pattern can trigger for operations
>> on three constants, and as things stood could endlessly oscillate
>> between the two associations.
>>
>> This patch keeps the existing pattern for the normal case of a
>> non-constant first operand. When all three operands are constant it
>> tries to find a pair of constants that do fold. If none do, it keeps
>> the original expression as-was.
>>
>> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linus-gnu.
>> OK to install?
>
> Hmm, is the complication with trying variants necessary or could we simply do
>
> if (!CONSTANT_CLASS_P (@0))
> (bitop @0 (bitop @1 @2))
>
> and be done with it?
That's enough to fix the oscillation, but there are cases that benefit
from trying the other combinations. E.g. if @1 and @2 are both
INTEGER_CSTs, it's still worth folding them. POLY_CST | INTEGER_CST
is supported for some values, so if @0 | @1 doesn't fold, it's worth
trying @0 | @2 instead.
Thanks,
Richard