This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR 23551: why should we coalesce inlined variables?
On Jul 9, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
> On Mon, 2007-07-09 at 13:24 -0300, Alexandre Oliva wrote:
> the fact of the matter is coalescing in out of
> ssa is going nowhere for a very long time.
No doubt about it.
> Think of it as coalescing running twice if you want. once one trees
> and once on rtl.
Problem is that this initial coalescing has already been shown to get
us worse performance in a number of situations. But what do I know?
> No, I'm saying the path you are heading down lead to death, destruction,
> and gnashing of teeth.
I'm not heading down any particular path yet. I'm probing
possibilities and discussing some pipe dreams along with immediate
needs. I guess this is as unclear as the fact that I'm not opposing
the reversal of the patch. Quite the contrary. I've posted one that
goes even further than that, addressing the same memory explosion
problem for the case in which that horrible testcase has all function
calls inlined by hand.
> I suggested a different approach which will make gobs of
> improvements on the debug info without affecting the compiler
> whatsoever.
So far I see the proposed improvements result in incorrect debug
information, which heavy users of debug information told me is worse
than not having debug information at all. So, more design is needed
before I can start coding.
>> Or have the register allocator take PHI notes in BB entry points into
>> account, inserting copies in case it doesn't manage to assign both
>> pseudos to the same location. Which, if SSA coalescing can do, then
>> so can a good register allocator.
> every other optimization will have to understand what a PHI node is.
Nah, very few RTL optimizations work across BBs.
> You are basing your assumptions that these things will be resolved
> in time.
I don't see where this impression comes from. To me they're very
unrelated.
>> Yup. But then, SSA makes things over basic blocks work like magic, so
>> I'm working first on getting stuff right inside basic blocks, to then
>> figure out how the PHI function handling ought to look like.
> You are making tactical decisions instead of strategic planning.
No, what I'm doing ATM is all planning. I'm not making any decisions.
I'm just past gathering requirements. Now I'm trying to figure out
how to retain the information I need within basic blocks.
When that's figured out, I expect figuring out how to perform
confluence of PHI nodes will be nearly trivial. If it's not, I'll
work harder on that. But until I have a plan for stuff to work within
basic blocks, I don't see the point of trying to address the more
complex scenarios.
Don't assume I'm jumping to coding. I'm not. Not at all.
>> > foo_1 =
>> > bar_2 =
>> > bar_4 - bar_2 + 1
>> > foo_5 = bar_2 - 1
>> > when we coalesced foo_3 and bar_2, to bar_2, we update the debug
>> > list for bar_2 to be 'foo' and 'bar'. then in out of ssa, we issue
>> > the debug info for both 'foo' and 'bar' to match the range of bar_2.
>> Do you realize that debug info will be wrong for foo in this case,
>> because it will appear to hold the same value as bar_2 starting at the
>> assignment to bar_2, while it should still hold the foo_1 value? This
>> is precisely one of the problems I'm trying to address.
> Which is why I said there is some twiddling to do with overlapping
> ranges. its not HARD to get right, its just a matter of conflict
> resolution for the cases which have multiple debug symbols associated
> with an ssa_name.
I really don't see how we can possibly recover the location of the
foo_3 assignment to perform the conflict resolution you're talking
about. What do you have in mind?
> I have provided another
> approach that is not so controversial, will provide much better info
> than we have, and will not force changes on so much of the compiler, and
> will have extremely minimal impact on compile time. I am happy to
> provide assistance and such if you want.
Yes, I'm exploring that path, but I'm trying to fit it with the
requirements before me, and I'm failing at that.
> Once that part is done, we can work on addressing further bits of
> debug info that incorrect and need to be addressed.
Do you realize that this is contrary to the very "plan ahead" approach
that you suggested to me, and that planning ahead is precisely what
I'm trying to do right now?
> I would like to see the patch reverted,
No disagreement here, but can you please comment on the patch I
proposed to revert and supersede the one I checked in? It's not like
there's an urgency in reverting that one before the revised one is
even commented on, is there?
> especially since we have seen a demonstration of significant
> negative side effects.
Which applies to other scenarios that the proposed patch will also
address. Want me to come up with a testcase that shows the same
explosion regardless of the patch I've checked in, and that the
pending patch I proposed will reduce memory use as much as reverting
the checked-in patch would do to the testcase that brought up all this
discussion?
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}