https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > before that region. If we can say for:
> > for (...)
> > {
> > unsigned char v[10];
> > unsigned char *p = foo (v);
> > *p = 1;
> > unsigned char w[10];
> > bar (w);
> > }
> > hoist the p = foo (v); call before the loop, then indeed we are in big
> > trouble.
>
> This is effectively what the testcase is doing (just that 'foo' is no call,
> but a normal address expression), so yes, we can do that, and yes we are in
> big
> trouble :-/
Well, that p = foo (v); or store of memory is something that will have (unless
const call, indeed) a vuse or even a vdef and the alias oracle should usually
consider it to be conflicting with the clobber stmt, so I'd hope it isn't
hoisted in that case, while for the pure address arithmetics there is nothing
that can easily stop the hoisting.
Now, if there isn't really an easy way out of this and given how rarely this
has been reported (I think we have this PR and PR61203, don't remember anything
else), the options can be do nothing, or do something simple that isn't that
expensive, will fix this testcase and while not perfect solution will still
allow variable sharing in the general case almost as often as before, or change
the IL representation so that such hoisting or sinking of addresses is not
possible.
