On January 15, 2021 9:03:58 PM GMT+01:00, Jakub Jelinek <ja...@redhat.com>
wrote:
>On Fri, Jan 15, 2021 at 08:50:20PM +0100, Richard Biener wrote:
>> On January 15, 2021 7:38:35 PM GMT+01:00, Jakub Jelinek
><ja...@redhat.com> wrote:
>> >Hi!
>> >
>> >The following patch generalizes the PR64309 simplifications, so that
>> >instead
>> >of working only with constants 1 and 1 it works with any two power
>of
>> >two
>> >constants, and works also for right shift (in that case it rules out
>> >the
>> >first one being negative, as it is arithmetic shift then).
>> >
>> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> Ok.
>
>Thanks.
>
>BTW, I've tried to also fix what the PR wanted primarily by adding
>/* Simplify (CST << x) & 1 to 0 if CST is even or to x == 0 if it is
>odd. /
>(simplify
> (bit_and (lshift INTEGER_CST@1 @0) integer_onep)
> (if ((wi::to_wide (@1) & 1) != 0)
> (eq @0 { build_zero_cst (TREE_TYPE (@0)); })
> ({ build_zero_cst (type); })))
>simplifier before this one, but genmatch.c doesn't seem to put it into
>the
>resulting files. Is there a way to figure out what is going on?
>
>I remember you said one can't have multiple too similar rules,
>but the closest one I can find is
>(for shift (lshift rshift)
> (simplify
> (bit_and (convert?:s@4 (shift:s@5 (convert1?@3 @0) INTEGER_CST@1))
> INTEGER_CST@2)
>Is it that one that makes the above not work and shall I then
>stick it into the same simplifier?
Hmm, genmatch should warn then (maybe only with -v). But yeah, it looks awfully
close (though INTEGER_CST vs. Integer_onep should make a difference...
You could try Debug genmatch with a smaller file containing just the two cases.
The intent is to diagnose 'dropped' patterns.
>What I want has the @1 in this one actually not an INTEGER_CST, while
>@3
>shall be INTEGER_CST...
>
> Jakub
