gcc.dg/debug/debug-[12].c failures on cmov targets

gcc.dg/debug/debug-[12].c failures on cmov targets

[Eric Botcazou]

Hi,

These two testcases fail on some targets with conditional moves (e.g. 
SPARC64) because a whole block is folded into the result at -O:

/* Verify that the scheduler does not discard the lexical block.  */
/* { dg-do compile } */
/* { dg-options "-dA" } */
/* { dg-final { scan-assembler "xyzzy" } } */
long foo(long p)
{
  {
    long xyzzy = 0;
    if (p)
      xyzzy = 2;
    return xyzzy;
  }
}

is folded into

long foo(long p)
{
   return p ? 2 : 0;
}

so the lexical block containing xyzzy is discarded and the variable with it.


Is this "fixable"? Is this worth "fixing"? Or can we XFAIL them, on the 
grounds that they don't exercise what they are supposed to?

-- 
Eric Botcazou

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Andrew Pinski]

On Dec 2, 2003, at 23:09, Eric Botcazou wrote:
> Is this "fixable"? Is this worth "fixing"? Or can we XFAIL them, on the
> grounds that they don't exercise what they are supposed to?


These two tests are already XFAIL on Powerpc because of the same reasons
(except it is not because of CMOV though).


Thanks,
Andrew Pinski

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Richard Henderson]

> so the lexical block containing xyzzy is discarded and the variable with it.

No, the lexical block should still exist.  I wrote this test for
Alpha, which also has conditional moves.  At -O2 -g I get:

        cmpult $31,$16,$0
        addq $0,$0,$0
        ret $31,($26),1

        .uleb128 0x5     # (DIE (0x70) DW_TAG_variable)
        .4byte  $LASF2   # DW_AT_name: "xyzzy"
        .byte   0x1      # DW_AT_decl_file
        .byte   0x4      # DW_AT_decl_line
        .4byte  0x7f     # DW_AT_type
        .byte   0x1      # DW_AT_location
        .byte   0x50     # DW_OP_reg0

That doesn't use cmov, but change the source to be = 20 and I get

        mov $31,$0
        cmovne $16,20,$0
        ret $31,($26),1

(which is 1 cycle slower on ev6, which is why we prefer the former
if we can use it).  I still get proper debug info for xyzzy.

You should dig deeper to determine where the block gets lost.


r~

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Richard Henderson]

I should add here, that if you're looking at stabs and not
dwarf2, that is the likely failure point.  IIRC other targets
have xfailed the test for that reason.


r~

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Eric Botcazou]

> I should add here, that if you're looking at stabs and not
> dwarf2, that is the likely failure point.  IIRC other targets
> have xfailed the test for that reason.

It's dwarf2, sparc64-sun-solaris2.* uses dwarf2 too.

-- 
Eric Botcazou

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Eric Botcazou]

> No, the lexical block should still exist.

Even when everything is folded into the result?


Here an excerpt of 36.dbr on SPARC64:

(note 32 1 3 [bb 0] NOTE_INSN_BASIC_BLOCK)

(note 3 32 4 NOTE_INSN_DELETED)

(note 4 3 10 NOTE_INSN_FUNCTION_BEG)

(note 10 4 12 ("debug-1.c") 9)

(note 12 10 37 ("debug-1.c") 10)

(note 37 12 14 NOTE_INSN_DELETED)

(note 14 37 17 ("debug-1.c") 11)

(note 17 14 25 ("debug-1.c") 12)

(note 25 17 26 NOTE_INSN_FUNCTION_END)

(note 26 25 39 ("debug-1.c") 14)

(insn 39 26 28 (set (reg:DI %g1)
        (const_int 0 [0x0])) 62 {*movdi_insn_sp64_novis} (nil)
    (nil))

(insn 28 39 31 debug-1.c:14 (set (reg:DI %g1)
        (if_then_else:DI (ne:DI (reg:DI %i0 [ p ])
                (const_int 0 [0x0]))
            (const_int 2 [0x2])
            (reg:DI %g1))) 118 {*movdi_cc_reg_sp64} (insn_list 39 (nil))
    (expr_list:REG_DEAD (reg:DI %i0 [ p ])
        (nil)))

(insn 31 28 38 debug-1.c:14 (use (reg/i:DI %i0 [ <result> ])) -1 (insn_list 
40 (nil))
    (nil))


and of 35.mach on Alpha:

(note 32 1 40 [bb 0] NOTE_INSN_BASIC_BLOCK)

(note 40 32 3 NOTE_INSN_PROLOGUE_END)

(note 3 40 4 NOTE_INSN_DELETED)

(note 4 3 10 NOTE_INSN_FUNCTION_BEG)

(note 10 4 12 ("debug-1.c") 9)

(note 12 10 39 ("debug-1.c") 10)

(insn 39 12 37 (set (reg/v:DI $0 [orig:71 xyzzy ] [71])
        (const_int 0 [0x0])) 259 {*movdi_nofix} (nil)
    (nil))

(insn 37 39 14 debug-1.c:11 (set (reg/v:DI $0 [orig:71 xyzzy ] [71])
        (if_then_else:DI (ne (reg:DI $16 [ p ])
                (const_int 0 [0x0]))
            (const_int 20 [0x14])
            (reg/v:DI $0 [orig:71 xyzzy ] [71]))) 168 {*movdicc_internal} 
(insn_list 39 (nil))
    (expr_list:REG_DEAD (reg:DI $16 [ p ])
        (nil)))

(note 14 37 17 ("debug-1.c") 11)

(note 17 14 25 ("debug-1.c") 12)

(note 25 17 26 NOTE_INSN_FUNCTION_END)

(note 26 25 31 ("debug-1.c") 14)

(insn 31 26 41 debug-1.c:14 (use (reg/i:DI $0 [ <result> ])) -1 (insn_list 37 
(nil))
    (nil))

(note 41 31 42 NOTE_INSN_EPILOGUE_BEG)

(jump_insn 42 41 43 debug-1.c:14 (return) 224 {*return_internal} (nil)
    (nil))


-- 
Eric Botcazou

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Richard Henderson]

On Thu, Dec 04, 2003 at 09:59:41AM +0100, Eric Botcazou wrote:
> Even when everything is folded into the result?

Yes.  At absolute minimum, the variable should still exist,
but have no associated AT_location, meaning that it has been
completely optimized away.  

I would hope that wouldn't happen in this case.  I would hope
that the variable gets allocated to the return register, which
is what happens on Alpha.

The lexical scope should *not* vanish.


r~

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Eric Botcazou]

> Yes.  At absolute minimum, the variable should still exist,
> but have no associated AT_location, meaning that it has been
> completely optimized away.

That's sort of what happens I think. The variable is still there, but since 
the function has no body anymore, the debug info emitting code doesn't try 
to emit debug info for what lies in the body.

> The lexical scope should *not* vanish.

Even when the body of the function itself vanishes?

-- 
Eric Botcazou

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Richard Henderson]

On Thu, Dec 04, 2003 at 10:19:57AM +0100, Eric Botcazou wrote:
> Even when the body of the function itself vanishes?

Were there zero instructions?  If not, why do you say
the body of the function vanished?


r~

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Eric Botcazou]

> Were there zero instructions?

No, roughly what is emitted on Alpha.

> If not, why do you say the body of the function vanished?

Because:

(note 4 3 10 NOTE_INSN_FUNCTION_BEG)

(note 10 4 12 ("debug-1.c") 9)

(note 12 10 37 ("debug-1.c") 10)

(note 37 12 14 NOTE_INSN_DELETED)

(note 14 37 17 ("debug-1.c") 11)

(note 17 14 25 ("debug-1.c") 12)

(note 25 17 26 NOTE_INSN_FUNCTION_END)


-- 
Eric Botcazou

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Richard Henderson]

On Thu, Dec 04, 2003 at 10:28:24AM +0100, Eric Botcazou wrote:
> (note 4 3 10 NOTE_INSN_FUNCTION_BEG)
...
> (note 25 17 26 NOTE_INSN_FUNCTION_END)

This shouldn't happen.  Why did it?


r~

Re: gcc.dg/debug/debug-[12].c failures on cmov targets

[Eric Botcazou]

> This shouldn't happen.  Why did it?

The combiner turned

;; Start of basic block 0, registers live: 14 [%sp] 24 [%i0] 31 [%i7] 101 
[%sfp]
(note 32 1 3 0 [bb 0] NOTE_INSN_BASIC_BLOCK)

(insn 3 32 4 0 debug-1.c:7 (set (reg/v:DI 108 [ p ])
        (reg:DI %i0 [ p ])) 62 {*movdi_insn_sp64_novis} (nil)
    (expr_list:REG_DEAD (reg:DI %i0 [ p ])
        (expr_list:REG_EQUIV (mem/f:DI (plus:DI (reg/f:DI %sfp)
                    (const_int 128 [0x80])) [0 p+0 S8 A64])
            (nil))))

(note 4 3 10 0 NOTE_INSN_FUNCTION_BEG)

(note 10 4 12 0 ("debug-1.c") 9)

(note 12 10 37 0 ("debug-1.c") 10)

(insn 37 12 14 0 debug-1.c:11 (set (reg/v:DI 109 [ xyzzy ])
        (if_then_else:DI (eq:DI (reg/v:DI 108 [ p ])
                (const_int 0 [0x0]))
            (const_int 0 [0x0])
            (const_int 2 [0x2]))) 118 {*movdi_cc_reg_sp64} (insn_list 3 
(nil))
    (expr_list:REG_DEAD (reg/v:DI 108 [ p ])
        (nil)))

(note 14 37 17 0 ("debug-1.c") 11)

(note 17 14 25 0 ("debug-1.c") 12)

(note 25 17 26 0 NOTE_INSN_FUNCTION_END)

(note 26 25 28 0 ("debug-1.c") 14)

(insn 28 26 31 0 debug-1.c:14 (set (reg/i:DI %i0 [ <result> ])
        (reg/v:DI 109 [ xyzzy ])) 62 {*movdi_insn_sp64_novis} (insn_list 37 
(nil))
    (expr_list:REG_DEAD (reg/v:DI 109 [ xyzzy ])
        (nil)))

(insn 31 28 0 0 debug-1.c:14 (use (reg/i:DI %i0 [ <result> ])) -1 (insn_list 
28 (nil))
    (nil))
;; End of basic block 0, registers live:
 14 [%sp] 24 [%i0] 31 [%i7] 101 [%sfp]

into

;; Start of basic block 0, registers live: 14 [%sp] 24 [%i0] 31 [%i7] 101 
[%sfp]
(note 32 1 3 0 [bb 0] NOTE_INSN_BASIC_BLOCK)

(note 3 32 4 0 NOTE_INSN_DELETED)

(note 4 3 10 0 NOTE_INSN_FUNCTION_BEG)

(note 10 4 12 0 ("debug-1.c") 9)

(note 12 10 37 0 ("debug-1.c") 10)

(note 37 12 14 0 NOTE_INSN_DELETED)

(note 14 37 17 0 ("debug-1.c") 11)

(note 17 14 25 0 ("debug-1.c") 12)

(note 25 17 26 0 NOTE_INSN_FUNCTION_END)

(note 26 25 28 0 ("debug-1.c") 14)

(insn 28 26 31 0 debug-1.c:14 (set (reg/i:DI %i0 [ <result> ])
        (if_then_else:DI (ne:DI (reg:DI %i0 [ p ])
                (const_int 0 [0x0]))
            (const_int 2 [0x2])
            (const_int 0 [0x0]))) 118 {*movdi_cc_reg_sp64} (nil)
    (nil))

(insn 31 28 0 0 debug-1.c:14 (use (reg/i:DI %i0 [ <result> ])) -1 (insn_list 
28 (nil))
    (nil))
;; End of basic block 0, registers live:
 14 [%sp] 24 [%i0] 31 [%i7] 101 [%sfp]


-- 
Eric Botcazou