On Mon, 18 Nov 2019, Jakub Jelinek wrote:
> 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).
Yes, we might run into the "wrong" one via binary op handling, so
there isn't really a conservative answer here :/
> 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.
Yeah. Or the weird ones are exposed by nonzero bits "optimizations"
of constants.
Richard.
