https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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.
