Re: 8 GCC regressions, 2 new, with your patch on 2003-04-16T21:21:05Z.

Re: 8 GCC regressions, 2 new, with your patch on 2003-04-16T21:21:05Z.

[Joern Rennecke]

GCC regression checker wrote:
...
> The new failures are:
> native gcc.sum gcc.dg/debug/debug-1.c
> native gcc.sum gcc.dg/debug/debug-2.c

Looking at the debug-1.c case, I see that the relevant transformation
was done in combine, no doubt do to the patch that I applied yesterday:
==================== before combine ==================================
(insn 47 45 15 0 0x401c8a7c (set (reg/v:SI 120 [ xyzzy ])
        (ashift:SI (reg:SI 126)
            (const_int 1 [0x1]))) 132 {ashlsi3_no_power} (insn_list 45 (nil))
    (expr_list:REG_DEAD (reg:SI 126)
        (nil)))
..
(insn 29 27 32 0 (nil) (set (reg/i:SI 3 r3 [ <result> ])
        (reg/v:SI 120 [ xyzzy ])) 314 {*movsi_internal1} (insn_list 47 (nil))
    (expr_list:REG_DEAD (reg/v:SI 120 [ xyzzy ])
        (nil)))
==================== after combine ===================================
(note 47 45 15 0 NOTE_INSN_DELETED)
..
(insn 29 27 32 0 (nil) (set (reg/i:SI 3 r3 [ <result> ])
        (ashift:SI (reg:SI 126)
            (const_int 1 [0x1]))) 132 {ashlsi3_no_power} (insn_list 45 (nil))
    (expr_list:REG_DEAD (reg:SI 126)
        (nil)))

on i386 and sh1..sh4, the return value is passed in a likely spilled register,
hence this failure was not triggered during my regression tests on these
targets.  Still, the transformation is safe, and I see nothing fundamentally
wrong with removing a variable in an optimizing compilation - yes, it makes
debugging harder, but then so do a lot of optimizations.

	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: 8 GCC regressions, 2 new, with your patch on 2003-04-16T21:21:05Z.

[Geoff Keating]

Joern Rennecke <joern.rennecke@superh.com> writes:

> GCC regression checker wrote:
> ...
> > The new failures are:
> > native gcc.sum gcc.dg/debug/debug-1.c
> > native gcc.sum gcc.dg/debug/debug-2.c
> 
> Looking at the debug-1.c case, I see that the relevant transformation
> was done in combine, no doubt do to the patch that I applied yesterday:
> ==================== before combine ==================================
> (insn 47 45 15 0 0x401c8a7c (set (reg/v:SI 120 [ xyzzy ])
>         (ashift:SI (reg:SI 126)
>             (const_int 1 [0x1]))) 132 {ashlsi3_no_power} (insn_list 45 (nil))
>     (expr_list:REG_DEAD (reg:SI 126)
>         (nil)))
> ..
> (insn 29 27 32 0 (nil) (set (reg/i:SI 3 r3 [ <result> ])
>         (reg/v:SI 120 [ xyzzy ])) 314 {*movsi_internal1} (insn_list 47 (nil))
>     (expr_list:REG_DEAD (reg/v:SI 120 [ xyzzy ])
>         (nil)))
> ==================== after combine ===================================
> (note 47 45 15 0 NOTE_INSN_DELETED)
> ..
> (insn 29 27 32 0 (nil) (set (reg/i:SI 3 r3 [ <result> ])
>         (ashift:SI (reg:SI 126)
>             (const_int 1 [0x1]))) 132 {ashlsi3_no_power} (insn_list 45 (nil))
>     (expr_list:REG_DEAD (reg:SI 126)
>         (nil)))
> 
> on i386 and sh1..sh4, the return value is passed in a likely spilled register,
> hence this failure was not triggered during my regression tests on these
> targets.  Still, the transformation is safe, and I see nothing fundamentally
> wrong with removing a variable in an optimizing compilation - yes, it makes
> debugging harder, but then so do a lot of optimizations.

I'm inclined to agree, can you come up with a testsuite patch?
 
-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: 8 GCC regressions, 2 new, with your patch on 2003-04-16T21:21:05Z.

[Richard Henderson]

On Thu, Apr 17, 2003 at 12:54:05PM +0100, Joern Rennecke wrote:
> Still, the transformation is safe, and I see nothing fundamentally
> wrong with removing a variable in an optimizing compilation - yes, it makes
> debugging harder, but then so do a lot of optimizations.

The original motivation for the test was a bit more 
complicated than that:

  http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02450.html

Interestingly, this test continues to pass with dwarf2:

        .uleb128 0x4    // (DIE (0x5c) DW_TAG_variable)
        data4.ua        @secrel(.LASF3) // DW_AT_name: "xyzzy"
        data1   0x1     // DW_AT_decl_file
        data1   0x9     // DW_AT_decl_line
        data4.ua        0x68    // DW_AT_type

Note that there is no DW_AT_location entry, so indeed
this variable has been optimized away, but the lexical 
block still exists, which is the real point of the test.

I guess stabs can't represent this.  I'd much prefer we
XFAIL these tests in that case rather than remove or
modify the test.

It's also a point that perhaps it would be best to remove
Dale's patch after the new register allocator is enabled
by default -- we'll get better debug information in that case.


r~