On Mon, Nov 25, 2024 at 11:52:31AM +0100, Uros Bizjak wrote:
> > Any reason for an exact comparison rather than
> > && (INTVAL (operands[3]) & (<MODE_SIZE> * BITS_PER_UNIT - 1)) == 0
> > ?
> > I mean, we can optimize this way 1U << (32 - x) or
> > 1U << (1504 - x) or any other multiply of 32.
>
> Count values outside of [0, bitwidth) are undefined in general. Also,
Sure, e.g. the 1504 - x case will be undefined if x is not in [1473, 1504]
But it very well could be in that range.
What I'm arguing about is that changing the test (in all the new patterns)
will not noticeably slow compilation down and be more general.
> during the bootstrap only values of 32 or 64 were found, so I thought
> to not complicate the condition too much
>
> FYI, the conversion triggers 504 times during the bootstrap, I somehow
> expected a lower number.
>
> > Similarly, we can optimize 1U << (32 + x) to 1U << x and
> > again do that for any other multiplies of 32.
>
> I don't think anybody uses the above idiom, it is valid only for
> certain targets (x86 and the ones that mask count argument), but
> undefined in general.
No, it is again valid whenever x is in [-32, -1] range, which it very well
could be (or if x is unsigned, in [-32U, -1U] range).
Of course if it is rare, adding new patterns for it might not be worth it.
But for the x << (CST - y) etc. we already have the patterns added by your
commit, so it is just about making them more generic.
Jakub
