On March 5, 2015 8:26:42 PM CET, Alexandre Oliva <aol...@redhat.com> wrote: >On Mar 4, 2015, Richard Biener <richard.guent...@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?
For the effect on tramp3d, yes. The positive effect on var-tracking compile time really looks good. So I'm tempted to approve the patch for 5.0. >> 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. I wonder why we use the same decl uid for two different inline instances though. Do we not remap them during inlining? Richard.
