[PATCH] Fix PR92462

[Jeff Law]

On 11/21/19 1:00 AM, Richard Biener wrote:
> On Wed, 20 Nov 2019, Jeff Law wrote:
> 
> Sure, but we're not being called with this but with RTL
> expanded via cselib usually:
> 
> (plus:SI (plus:SI (and:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
>             (const_int 3 [0x3]))
>         (value:SI 8:8 @0x3089c18/0x30f5e40))
>     (const_int -8 [0xfffffffffffffff8]))
Ugh.  I'm suspect all the ANCHOR stuff came in well after the original
code to try and optimize the low-order bit-logical masking for addressing.

Without knowing something more, I'd claim that can't actually be a pointer.

> 
> so there are no REGs involved on the "subexpressions" we could
> check REG_POINTER on ... and in fact the symbol_ref _is_
> a pointer!  It's just not something we should consider the
> base of the memory reference.  We're talking about sth like
> 
> *(&a + ((uintptr_t)&b - (uintptr_t)&a))
> 
> where it's nearly impossible to tell (on RTL, if the address
> parts are not split to separate insns and thus REG_POINTER is
> applicable) what object we are looking at for aliasing purposes.
Right.  And in that case we have to make the most conservative
assumptions.


> 
> The appropriate way here is to not to too clever things with
> the address but instead rely on MEM_EXPR here - unfortunately
> that is non-existent for spill slots which is where most of
> the regressions with removing the code appear.
That's what doesn't make much sense to me.  We ought to be able to
analyze stack slots reasonably well.  But the RTL DSE bits have changed
a lot since Christian's  implementation  -- it actually used to be easy
to follow.


jeff