On Wed, Jun 3, 2015 at 11:55 PM, Alexandre Oliva aol...@redhat.com wrote:
On Feb 25, 2015, Alexandre Oliva aol...@redhat.com wrote:
This patch fixes a problem that has been with us for several years.
Variable tracking has no idea about the end of the lifetime of inlined
variables, so it keeps
On Feb 25, 2015, Alexandre Oliva aol...@redhat.com wrote:
This patch fixes a problem that has been with us for several years.
Variable tracking has no idea about the end of the lifetime of inlined
variables, so it keeps on computing locations for them over and over,
even though the computed
On Mar 9, 2015, Jeff Law l...@redhat.com wrote:
On 03/09/15 08:38, Richard Biener wrote:
On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva aol...@redhat.com wrote:
On Feb 26, 2015, Alexandre Oliva aol...@redhat.com wrote:
So far, all the differences I looked at were caused by padding at the
On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva aol...@redhat.com wrote:
On Feb 26, 2015, Alexandre Oliva aol...@redhat.com wrote:
So far, all the differences I looked at were caused by padding at the
end of BBs, and by jump stmts without line numbers at the end of BBs,
both right after the
On 03/09/15 08:38, Richard Biener wrote:
On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva aol...@redhat.com wrote:
On Feb 26, 2015, Alexandre Oliva aol...@redhat.com wrote:
So far, all the differences I looked at were caused by padding at the
end of BBs, and by jump stmts without line numbers
On Feb 26, 2015, Alexandre Oliva aol...@redhat.com wrote:
So far, all the differences I looked at were caused by padding at the
end of BBs, and by jump stmts without line numbers at the end of BBs,
both right after the debug reset stmts the proposed patch introduces.
Further investigation
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
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
On Wed, Feb 25, 2015 at 10:40 AM, Alexandre Oliva aol...@redhat.com wrote:
This patch fixes a problem that has been with us for several years.
Variable tracking has no idea about the end of the lifetime of inlined
variables, so it keeps on computing locations for them over and over,
even
On Feb 27, 2015, Petr Machata pmach...@redhat.com wrote:
Alexandre Oliva aol...@redhat.com writes:
Ok, I looked into it further, after patching dwlocstat to dump
per-variable per-range coverage/length info, so as to be able to compare
object files more easily.
If you send me those patches,
Alexandre Oliva aol...@redhat.com writes:
Ok, I looked into it further, after patching dwlocstat to dump
per-variable per-range coverage/length info, so as to be able to compare
object files more easily.
If you send me those patches, I can finish them, bind the functionality
to a command line
Jakub Jelinek ja...@redhat.com writes:
it counts on what percentage of bytes in those ranges (or instructions?)
the variable has defined location.
Yes, it counts bytes. It doesn't know anything about instruction
lengths etc.
Thanks,
Petr
On Feb 25, 2015, Alexandre Oliva aol...@redhat.com wrote:
if a function is called within a loop and we inline it, bindings from
the call in one iteration of the loop will carry over onto the
subsequent iteration until a new binding occurs.
Wait, I have to take that back and revisit the code I
On Feb 26, 2015, Richard Biener richard.guent...@gmail.com wrote:
After all if the inliner inserts resets just for vars that already
have debug stmts then I cook up a testcase where those debug stmts
only appear after inlining.
Please try that.
Hint: the actual requirement is that the
On Feb 26, 2015, Richard Biener richard.guent...@gmail.com wrote:
and more concentrating on the effect of your patch as opposed to
debug stmt philosophy.
(which looks reasonable minus code-motion issues).
(but we might still want to compute it during var-tracking
if at a later PC range the
On Thu, Feb 26, 2015 at 1:01 AM, Alexandre Oliva aol...@redhat.com wrote:
On Feb 25, 2015, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 25, 2015 at 06:17:33PM -0300, Alexandre Oliva wrote:
My measurements, for a not particularly unusual testcase, showed an
overall reduction of 63% in
On Thu, Feb 26, 2015 at 11:29:35AM +0100, Richard Biener wrote:
I claim you can achieve the same result by effectively inserting
those reset debug insns right before var-tracking itself and by
re-computing BLOCK liveness. That will automatically deal
with code motion that extends the
On Thu, Feb 26, 2015 at 11:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Feb 26, 2015 at 11:29:35AM +0100, Richard Biener wrote:
I claim you can achieve the same result by effectively inserting
those reset debug insns right before var-tracking itself and by
re-computing BLOCK liveness.
On Feb 26, 2015, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 25, 2015 at 09:01:09PM -0300, Alexandre Oliva wrote:
On Wed, Feb 25, 2015 at 06:17:33PM -0300, Alexandre Oliva wrote:
My measurements, for a not particularly unusual testcase, showed an
overall reduction of 63% in compile
On Wed, Feb 25, 2015 at 11:54:16AM +0100, Richard Biener wrote:
Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install?
But code-motion could still move stmts from the inlined functions
across these resets? That said - shouldn't this simply performed
by proper var-tracking
On Feb 25, 2015, Richard Biener richard.guent...@gmail.com wrote:
But code-motion could still move stmts from the inlined functions
across these resets?
Sure, just like it could still move stmts across any other debug stmts.
Once you return from a function, it's as if all of its variables
On Wed, Feb 25, 2015 at 06:17:33PM -0300, Alexandre Oliva wrote:
My measurements, for a not particularly unusual testcase, showed an
overall reduction of 63% in compile time, as indicated yesterday. Now,
who should bear the burden of collecting evidence to back up the claims
against the
On Feb 25, 2015, Jakub Jelinek ja...@redhat.com wrote:
various tools and users really want to
be able to inspect variables and parameters on the return statement.
This patch won't affect the return statement. The resets are at the
return-to statement; if you stop at the return statement
On Feb 25, 2015, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 25, 2015 at 06:17:33PM -0300, Alexandre Oliva wrote:
My measurements, for a not particularly unusual testcase, showed an
overall reduction of 63% in compile time, as indicated yesterday. Now,
who should bear the burden of
On Wed, Feb 25, 2015 at 09:01:09PM -0300, Alexandre Oliva wrote:
On Wed, Feb 25, 2015 at 06:17:33PM -0300, Alexandre Oliva wrote:
My measurements, for a not particularly unusual testcase, showed an
overall reduction of 63% in compile time, as indicated yesterday. Now,
who should bear the
On Wed, Feb 25, 2015 at 10:40 AM, Alexandre Oliva aol...@redhat.com wrote:
This patch fixes a problem that has been with us for several years.
Variable tracking has no idea about the end of the lifetime of inlined
variables, so it keeps on computing locations for them over and over,
even
This patch fixes a problem that has been with us for several years.
Variable tracking has no idea about the end of the lifetime of inlined
variables, so it keeps on computing locations for them over and over,
even though the computed locations make no sense whatsoever because the
variable can't
27 matches
Mail list logo
