On Mon, Nov 18, 2019 at 11:07:22AM +0100, Richard Biener wrote:
> On Mon, 18 Nov 2019, Jakub Jelinek wrote:
>
> > On Mon, Nov 18, 2019 at 10:44:14AM +0100, Richard Biener wrote:
> > > The following adjusts the find_base_{term,value} heuristic when
> > > looking through ANDs to the case where it is obviously not
> > > aligning a base (when the LSB is set).
> >
> > What is specific about the LSB? I mean & 2 is obviously not an aligning
> > AND either.
>
> It aligns 0x1 and 0x3 ;)
>
> > Shouldn't we recurse only if the CONST_INT_P operand has
> > some set bits followed by clear bits, i.e. after the != 0 check
> > compute ctz_hwi and verify that INTVAL >> ctz == -1?
>
> I thought of more advanced heuristics but I guess that
> any contiguous set of bits with LSB unset might be aligning
> if the programmer knows upper bits are zero anyways? So I fear
> the == -1 test would not work reliable?
I'd say once a user does & 0x1ff8 or similar, he is doing something weird,
and not recursing is the conservatively correct answer (or maybe it isn't?
Aren't there cases where we punt if from a binary op we get base terms from
both sides and just use one if we get it only from one side? If so,
we might need to have some kind of annotated return, this could have a base
term but please don't use it).
I guess the only non-weird case would be if the target has weird pointer
sizes and only has larger or smaller ints, say 24-bit pointer, and 8/16/32
integers, so the aligning then could be & 0xfffff8 etc.
Jakub
