Alexandre Oliva writes:
> +int
> +main ()
> +{
> + int i;
> + char c;
> + char arr[11];
> +
> + for (i = 0; i < 10; i++)
> +{
> + c = 0x30 + i;
> + foo (&arr[i], c); /* { dg-final { gdb-test 24 "i" "c - 48" } } */
> +}
> +
> + __builtin_printf ("arr = %s\n", arr);
The stri
On 11/03/2012 10:11 AM, Alexandre Oliva wrote:
On Nov 2, 2012, Alexandre Oliva wrote:
On Nov 1, 2012, Jakub Jelinek wrote:
Even for stmt frontiers it is IMHO undesirable to duplicate
(perhaps many times) the whole sequence, as one would then reply the var
changing sequence in the debugger
On Nov 3, 2012, Jakub Jelinek wrote:
> On Sat, Nov 03, 2012 at 02:11:22PM -0200, Alexandre Oliva wrote:
>> I didn't try delaying the creation of the pointer set as you did, but
>> I'm now thinking using a linear on-stack vector for searches up to some
>> size might be even faster than creating t
On Sat, Nov 03, 2012 at 02:11:22PM -0200, Alexandre Oliva wrote:
> I didn't try delaying the creation of the pointer set as you did, but
> I'm now thinking using a linear on-stack vector for searches up to some
> size might be even faster than creating the pointer set at the first
> var.
THat woul
On Nov 2, 2012, Alexandre Oliva wrote:
> On Nov 1, 2012, Jakub Jelinek wrote:
>> Even for stmt frontiers it is IMHO undesirable to duplicate
>> (perhaps many times) the whole sequence, as one would then reply the var
>> changing sequence in the debugger perhaps once in the original bb, then
>>
On Nov 1, 2012, Jakub Jelinek wrote:
> Even for stmt frontiers it is IMHO undesirable to duplicate
> (perhaps many times) the whole sequence, as one would then reply the var
> changing sequence in the debugger perhaps once in the original bb, then
> once or many times again in the successor bb.
On 11/02/2012 02:08 AM, Jakub Jelinek wrote:
On Thu, Nov 01, 2012 at 10:27:57AM +0100, Jakub Jelinek wrote:
The patch unfortunately doesn't speed test-tgmath2.i compilation
significantly, but decreases number of debug stmts from ~ 36000 to ~ 16000,
the 2+ were clearly redundant.
Testing fo
On Thu, Nov 01, 2012 at 10:27:57AM +0100, Jakub Jelinek wrote:
> The patch unfortunately doesn't speed test-tgmath2.i compilation
> significantly, but decreases number of debug stmts from ~ 36000 to ~ 16000,
> the 2+ were clearly redundant.
Testing found a buglet in the patch (doing is_gimple_
On Fri, Oct 26, 2012 at 04:30:41AM -0200, Alexandre Oliva wrote:
> From: Alexandre Oliva
>
> for gcc/ChangeLog
>
> PR debug/54693
> * tree-ssa-threadedge.c (thread_around_empty_block): Copy
> debug temps from predecessor before threading.
As can be seen on test-tgmath2.i, unf
On Wed, Oct 31, 2012 at 01:13:28AM -0200, Alexandre Oliva wrote:
> From: Alexandre Oliva , Jakub Jelinek
>
> for gcc/ChangeLog
>
> PR debug/54693
> * tree-ssa-loop-ivopts.c (remove_unused_ivs): Emit debug temps
> for dropped IV sets.
Ok, thanks.
Jakub
On Oct 30, 2012, Alexandre Oliva wrote:
>> BTW, I'd also think that the first loop should set count = 2 if
>> the debug stmt already has a non-trivial expression
> Good! Will do.
Here's the revised patch. Bootstrap completed, test nearly finished.
Ok to install if it passes?
Replace PHI node
On Oct 30, 2012, Jakub Jelinek wrote:
> On Tue, Oct 30, 2012 at 03:51:19PM +0100, Richard Biener wrote:
>> + if (!comp)
>> + BREAK_FROM_IMM_USE_STMT (imm_iter);
>> how does comp magically become NULL_TREE here?
> Looks like pasto to me, from the first loop.
Mo
On Tue, Oct 30, 2012 at 03:51:19PM +0100, Richard Biener wrote:
> + FOR_EACH_IMM_USE_STMT (stmt, imm_iter, def)
> + {
> + if (!gimple_debug_bind_p (stmt))
> + continue;
> +
> + FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
> +
On Fri, Oct 26, 2012 at 8:30 AM, Alexandre Oliva wrote:
> Both jump threading and loop induction variable optimizations were
> dropping useful debug information, and it took improvements in both for
> debug info about relevant variables in the enclosed testcase to survive
> all the way to the end.
On Oct 26, 2012, Jakub Jelinek wrote:
> On Fri, Oct 26, 2012 at 04:30:41AM -0200, Alexandre Oliva wrote:
>> From: Alexandre Oliva
Fixed .git/config and the patches to use my @redhat.com address for
these patches.
>> +++ b/gcc/testsuite/gcc.dg/guality/pr54693.c
> The #include looks useless t
On 10/26/2012 11:51 AM, Jakub Jelinek wrote:
The debug stmts are already in SSA form, and, being debug stmts, they are
always just consumers of SSA names, not defining stmts, and Alex' patch
is just copying them over from a predecessor bb to a successor bb that
has a single predecessor (the one f
On Fri, Oct 26, 2012 at 11:42:20AM -0600, Jeff Law wrote:
> On 10/26/2012 12:30 AM, Alexandre Oliva wrote:
> >Propagate debug stmts for jump threading
> >for gcc/ChangeLog
> >
> > PR debug/54693
> > * tree-ssa-threadedge.c (thread_around_empty_block): Copy
> > debug temps from predece
On 10/26/2012 12:30 AM, Alexandre Oliva wrote:
Propagate debug stmts for jump threading
From: Alexandre Oliva
for gcc/ChangeLog
PR debug/54693
* tree-ssa-threadedge.c (thread_around_empty_block): Copy
debug temps from predecessor before threading.
So my only concerns h
On Fri, Oct 26, 2012 at 04:30:41AM -0200, Alexandre Oliva wrote:
> From: Alexandre Oliva
>
> for gcc/ChangeLog
>
> PR debug/54693
> * config/i386/i386.c (add_parameter_dependencies): Stop
> backward scan at the insn before the incoming head.
> (ix86_dependencies_evaluati
Both jump threading and loop induction variable optimizations were
dropping useful debug information, and it took improvements in both for
debug info about relevant variables in the enclosed testcase to survive
all the way to the end.
The first problem was that jump threading could bypass blocks c
20 matches
Mail list logo
