This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR58315] reset inlined debug vars at return-to point


On Mar  4, 2015, Richard Biener <richard.guenther@gmail.com> wrote:

> Compile-time was slightly faster with the patch, 45s vs. 47s,
> but the machine wasn't completely un-loaded.  var-tracking parts:

> unpatched:

>  variable tracking       :   0.63 ( 1%) usr   0.03 ( 1%) sys   0.82 (
> 2%) wall   28641 kB ( 2%) ggc
>  var-tracking dataflow   :   3.72 ( 8%) usr   0.04 ( 1%) sys   3.65 (
> 7%) wall    1337 kB ( 0%) ggc
>  var-tracking emit       :   2.63 ( 6%) usr   0.02 ( 1%) sys   2.55 (
> 5%) wall  148835 kB ( 8%) ggc

> patched:

>  variable tracking       :   0.64 ( 1%) usr   0.01 ( 0%) sys   0.72 (
> 1%) wall   24202 kB ( 1%) ggc
>  var-tracking dataflow   :   1.96 ( 4%) usr   0.01 ( 0%) sys   1.94 (
> 4%) wall    1326 kB ( 0%) ggc
>  var-tracking emit       :   1.46 ( 3%) usr   0.02 ( 0%) sys   1.49 (
> 3%) wall   46980 kB ( 3%) ggc

> we have at the point of RTL expansion 56% more debug statements
> (988231 lines with # DEBUG in the .optimized dump out of
> 1212518 lines in total vs. 630666 out of 854953).  So we go from
> roughly 1 debug stmt per real stmt to 1.5 debug stmts per real stmt.

So, if I got this right, all these extra debug stmts and insns had no
effect whatsoever on compile time proper.  The reduction in compile time
can be entirely accounted for by the time they save in the var-tracking
parts, and any compile time increase they bring about in other passes is
negligible.

Does this match your assessment of the impact of the patch?


> we have two pairs of DEBUG stmts for dD.570173 here, binding
> to _25 and then immediately resetting.

They're at different lines, and associated with different statements, so
once we have stmt frontiers support in GCC and GDB, you will be able to
stop between them an inspect the state, regardless of the absence of
executable code between them.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]