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 7/8/07, Alexandre Oliva <aoliva@redhat.com> wrote:
On Jul 8, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
> On 7/8/07, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Jul 7, 2007, Jan Hubicka <hubicka@ucw.cz> wrote:
>>
>> >> On Jun 28, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
>> >>
>> >> > I fooled around with some simple cases, and didn't find anything that
>> >> > made much difference. Whats a testcase you have which shows this
>> >> > helping?
>> >>
>> >> Err... I'm sure I had something when I posted the patch, but the
>> >> build tree in which I came up with the testcase is long gone, and I no
>> >> longer remember the details. On a more recent build tree, I couldn't
>> >> really find any case in which the patch really made a difference as to
>> >> debug info :-(
> Given the above
>> > this patch seems to be responsible for 90% memory consumption increase
>> > at rtl-optimization/28071 -O3:
> and this
>> And rightly so, I guess. Formerly, we discarded information to the
>> point of making the program utterly undebuggable.
> this can't be true and so I propose to revert this patch for now.
It is just as true. Before the patch, we discarded the information
earlier. Now, we still discard it, just a bit later in the process.
Anyhow, the testcase in that PR is absolutely unusual.
For you, maybe.
For others, it is normal.
I don't think
we can or should use it as a basis to guide our decisions on how to
make the debug information emitted by the compiler useful for the
regular user.
This is optimized code anyway. Nothing you ever do, short of tracking
every thing that happens to every single variable, through every
single pass, is going to save your debug info for -O2+.
Really.
I do know that discarding inlined variables is hurting
our users right now.
Just so we are straight here, o the ones who debug at -O2 -g are
normal, but the people who make code like the testcase are unusual.
:)
If you compile that same testcase with -O2 rather than -O3, thus reducing the amount of inlining you get, you'll
get nowhere as much of a memory hit.
And you'd reduce it's performance by a factor of 2, IIRC.
Honestly, if your patch had increased memory consumption by say, 5%
that would be one thing.
This isn't even close.
You've double it from 1 gigabyte to 2 gigabytes.
That's just a "memory hit".
T