https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Richard Biener from comment #10)
> > (In reply to Jakub Jelinek from comment #9)
> > > Created attachment 46312 [details]
> > > gcc10-pr90348.patch
> > >
> > > Untested patch that implements what was written in #c5. I agree that
> > > without further changes to the IL, determining if one can hoist addresses
> > > of
> > > local variables or not is going to be hard, would require computing the
> > > variable life info in each pass that would do something similar. On the
> > > other side, admittedly such hoisting results in worse code generation
> > > because if the address is hoisted earlier than where it used to be live
> > > before, then there will be more stack conflicts.
> >
> > Ick. You need to handle pt->anything and pt->escaped (walk the escaped
> > solution) as well. And !SSA_NAME_PTR_INFO (op) is of course the same
> > as pt->anything.
>
> Do I?
> I thought I don't. The thing is, I believe the partitioning only cares
> about where (originally in the source) the automatic variables are
> referenced.
> Now, if I have say:
> __attribute__((noipa)) type *foo (type *x) { return x; }
> or similar, in order for a variable to be live before the clobber, it needs
> to escape in the area where the variable is live, we don't care what we do
> with whatever it returned, unless we actually hoist such escaping calls
> 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.
> But if we can't, the attached patch was just meant as a shorthand for trying
> to do a dataflow propagation of the can a pointer SSA_NAME point to variable
> xyz, if we don't consider escaping (to other functions and to global state).
> What I'm trying to "undo" is just the hoisting of the address loads, not
> hoisting of those address loads plus function calls in which it escapes or
> where that address is saved to memory.
>
> If I have to consider pt->anything and pt->escaped, then it will be as
> useless for the variable conflicts as is removing the important clearing of
> the bitmap bit on clobber stmt, we won't share stack slots pretty much at
> all.
The point about !SSA_NAME_PTR_INFO is that passes might clear it, replace
such SSA name with a new one, forgetting to copy it, etc. The point
about anything is that points-to analysis might just have given up
(consider the provenance thing where we might end up with anything for
going through some uintptr arithmetic), the point about escaped is that
this is just a placeholder for a set of variables and points-to tends
to shrink sets by removing bits also in escaped. Also
global = ptr; ptr2 = global; will have escaped in the sets but not
necessarily the bit of the original decl.
So my comments are just about correctly interpreting points-to data.
