On Wed, Jun 3, 2015 at 11:55 PM, Alexandre Oliva wrote:
> On Feb 25, 2015, Alexandre Oliva 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
On Feb 25, 2015, Alexandre Oliva 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 locations make
On Mar 9, 2015, Jeff Law wrote:
> On 03/09/15 08:38, Richard Biener wrote:
>> On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva wrote:
>>> On Feb 26, 2015, Alexandre Oliva wrote:
>>>
So far, all the differences I looked at were caused by padding at the
end of BBs, and by jump stmts wi
On 03/09/15 08:38, Richard Biener wrote:
On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva wrote:
On Feb 26, 2015, Alexandre Oliva 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
On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva wrote:
> On Feb 26, 2015, Alexandre Oliva 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 propos
On Feb 26, 2015, Alexandre Oliva 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 showed there were
On March 5, 2015 8:26:42 PM CET, Alexandre Oliva wrote:
>On Mar 4, 2015, Richard Biener 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
On Mar 4, 2015, Richard Biener 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-
On Wed, Feb 25, 2015 at 10:40 AM, Alexandre Oliva 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 Feb 27, 2015, Petr Machata wrote:
> Alexandre Oliva 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 f
Alexandre Oliva 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 option, and me
On Feb 26, 2015, Jakub Jelinek 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 time,
On Feb 26, 2015, Richard Biener 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 scope will be active
On Feb 25, 2015, Alexandre Oliva 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 looked at.
var
On Feb 26, 2015, Richard Biener 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 VTA-trackable var has been
rem
Jakub Jelinek 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 Thu, Feb 26, 2015 at 11:42 AM, Jakub Jelinek 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". That wi
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 lif
On Thu, Feb 26, 2015 at 1:01 AM, Alexandre Oliva wrote:
> On Feb 25, 2015, Jakub Jelinek 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
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
On Feb 25, 2015, Jakub Jelinek 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 collecting ev
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 ch
On Feb 25, 2015, Jakub Jelinek 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 (assuming you
have c
On Feb 25, 2015, Richard Biener 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 ceased
to exist, so what is t
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 Wed, Feb 25, 2015 at 10:40 AM, Alexandre Oliva 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
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 eve
27 matches
Mail list logo
