This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: VTA merge - introduction
On Fri, Jun 5, 2009 at 8:10 PM, Alexandre Oliva<aoliva@redhat.com> wrote:
> On Jun ?5, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>
>> Looking at the IL at the end of tree compilation I still see that more than
>> 50% of all instructions are of DEBUG kind. ?And there are lots of
>> redundancies like
>
>> ? # DEBUG indexD.160664 => 0
>> ? # DEBUG cD.160665 => 0
>> ? # DEBUG cD.160665 => 0
>> ? # DEBUG indexD.160664 => 0
>
> Are the locations (line numbers) of these statements different? ?If they
I don't know.
> are, it's different statements we're talking about, and there's this
> thought of representing it so that you could step through side effects
> that didn't generate code, in much the same way that GDB enables you
> today to step into or out of an inlined function without changing the
> PC.
Uh. And this is useful for what? Yes, that is a serious question.
> Anyhow, I'm certainly willing to look into running the existing
> duplicate-removal code more often, if it would help. ?Smallish testcases
> that demonstrate the problem would be welcome, although I'm sure I
> wouldn't have much trouble coming up with some of my own ;-)
>
>> DEBUG insns also seem to keep unused local variables available until
>> var-tracking as can be seen with the following testcase:
>
> available in what sense? ?If this kept the variable available as in it
> got a stack slot, this would have been flagged by -fcompare-debug, so
> you must be speaking of something else. ?I can't tell what it is.
Available in the sense that it is still in the IL and the variable lists
and thus consumes memory and compile-time during stmt walks.
Note that this is for non-registers in this case, so we do not even print
<value optimized out> during debugging.
Richard.