This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Fix PR tree-optimization/21407
On Tue, 2005-05-10 at 15:10 -0700, Mark Mitchell wrote:
> Daniel Berlin wrote:
> >>It would seem rather dangerous to me to implement this optimization.
> > Again, it's been implemented and turned on for a couple months now, it's
> > not a proposal. :)
> Good point.
> > However, here is a patch to fully disable it and leave a note in it's
> > place for people who think of the same idea in the future.
> > I've added 21407 testcase to g++.dg/tree-ssa
> > Bootstrapped and regtested on i686-pc-linux-gnu
> > okay for mainline?
> Kenny and I had a long conversation today, and we think we have a
> proposal that will satisfy both of us -- though we can't be sure about
> Geoff, et. al. The current state is that I transcribed the proposal,
> sent it to Kenny, and am waiting for him to confirm that it matches his
> understanding of what we think we agreed upon. If it does, we'll post
> it soon. Since it would leave these bits in, I think we should hold off
> on your patch for the moment.
Even if you were to do something like move the behavior into an optional
attribute, that patch would have to be applied, and the code removed,
because call clobbering doesn't currently work in a way where you can
easily say "for this call, don't clobber those variables".
It's completely per function. Either a variable is call clobbered, in
which case it's clobbered by *every* call in the function, or it isn't.
The function that i modified is called "note_addressable", and is simply
determining what variables have had their addresses taken.
It is called from the SSA operand scanner.
Call clobbering uses the results as a consumer through a call to
Because, there is no "real" per-callsite clobbering at all right now,
in order to move the behavior that we currently have into an attribute,
you'd have to do one of the following:
1. add a flag to note_addressable and propagate it all the way from the
operand scanner calls downwards (which is incredibly ugly)
2. post-filter the call clobbered variables, which in this case, is very
hard since we don't know which are being passed as which arguments, so
something would have to go looking at the calls and set up bitmaps we
can intersect with the call-clobbered list.
3. Move the code/rework call clobbering so that it does it in the
"standard" way (IE some real intraprocedural/interprocedural escape
analysis or mod/ref instead of "is our address taken anywhere in the
function that could matter"
This is actually one of the reasons i'm anxious to do some stuff on
interprocedural call clobbering: So we can decide what to clobber on a
per-callsite basis without affecting anything else and without all this