match.pd handling of three-constant bitops
Richard Biener
richard.guenther@gmail.com
Thu Sep 21 11:42:00 GMT 2017
On Thu, Sep 21, 2017 at 1:17 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> 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.
Hmm, ok.
The patch is ok then if you add a comment reflecting the above.
Thanks,
Richard.
>
> Thanks,
> Richard
More information about the Gcc-patches
mailing list