On Mon, Apr 20, 2015 at 10:55:56AM +0200, Jakub Jelinek wrote:
> On Mon, Apr 20, 2015 at 06:12:26PM +0930, Alan Modra wrote:
> > I had it that way in my first patch, then decided to try deleting..
> >
> > I can certainly change it back even if only to do it the standard way
> > for safety's sake, but I'm curious as to why they can't be deleted in
> > this special case. My thinking was that we're on a chain of blocks
> > starting at the entry where there is a single outgoing live edge for
> > the register being used. So there shouldn't be any need for a debug
> > insn to mark info about the variable as invalid.
>
> The debug insns can be for arbitrary variables, there is no "the variable",
Sure.
> and there could be other debug insns for the same variable on that path,
> say saying that decl lives in some other register, or can be computed using
> an expression involving other registers, or memory etc. Say you could have
Yes, that's true in the general case. For the shrink-wrap case, any
bb (or tail of the entry block) that we move over has no use or def of
the register. So I'm left wondering how it would be possible for the
var to live in some other register or memory? Probably lack of
imagination on my part, but the only scenarios I see would involve a
failure of cse.
Anyway, I rewrote the patch to do as you suggested, and started
looking at .debug_loc in gcc/*.o for files that differed between the
two approaches. (Only 32 files differed, besides the expected
shrinkwrap.o and checksum files.) That was a bit of a revelation,
and no wonder powerpc debugging is such a pain..
The first file I looked at was reload.o, and the first difference is
in location lists for get_secondary_mem mode param. It looks like
virgin:
000086c5 0000000000005c90 0000000000005cd7 (DW_OP_reg4 (r4))
000086d8 0000000000005cd7 0000000000005cd8 (DW_OP_GNU_entry_value:
(DW_OP_reg4 (r4)); DW_OP_stack_value)
000086ee 0000000000005cd8 0000000000005cf8 (DW_OP_reg30 (r30))
00008701 0000000000005d2c 0000000000005d38 (DW_OP_reg30 (r30))
delete:
000086ae 0000000000005c90 0000000000005cd7 (DW_OP_reg4 (r4))
000086c1 0000000000005cd7 0000000000005ec0 (DW_OP_GNU_entry_value:
(DW_OP_reg4 (r4)); DW_OP_stack_value)
zap:
000086ae 0000000000005c90 0000000000005cd7 (DW_OP_reg4 (r4))
000086c1 0000000000005cd7 0000000000005cd8 (DW_OP_GNU_entry_value:
(DW_OP_reg4 (r4)); DW_OP_stack_value)
and the code:
5cd0: 48 00 00 01 bl 5cd0
<._Z17get_secondary_memP7rtx_def12machine_modei11reload_type+0x40>
5cd0: R_PPC64_REL24
_Z35rs6000_secondary_memory_needed_mode12machine_mode
5cd4: 60 00 00 00 nop
5cd8: 7c 7d 07 b4 extsw r29,r3
5cdc: 1f fd 00 1e mulli r31,r29,30
5ce0: 7d 3f da 14 add r9,r31,r27
5ce4: 79 29 1f 24 rldicr r9,r9,3,60
5ce8: 7d 3c 4a 14 add r9,r28,r9
5cec: e9 29 55 a8 ld r9,21928(r9)
5cf0: 2f a9 00 00 cmpdi cr7,r9,0
5cf4: 41 9e 00 3c beq cr7,5d30
<._Z17get_secondary_memP7rtx_def12machine_modei11reload_type+0xa0>
5cf8: 38 21 00 c0 addi r1,r1,192
5cfc: 7d 23 4b 78 mr r3,r9
..rest of epilogue
5d30: 7b b9 1f 24 rldicr r25,r29,3,60
5d34: 7c 7e 1b 78 mr r30,r3
5d38: 7f 1c ca 14 add r24,r28,r25
Arrgh! In the first place the ranges are wrong since r4 dies after
the bl, not the toc restoring nop. Worse, both deleting and zapping
(ie UNKNOWN_VAR_LOC) the debug insn is wrong. My simplistic patch
isn't correct. In fact it makes the debug info worse. However,
leaving the debug insn alone says "mode" lives in r30, but that is
wrong since the copy to r30 insn has been moved, to 5d34. Apparently
the move causes the virgin location lists to say "mode" disappears at
that point too. What a mess!
Of course, all this moving for shrink-wrap is senseless in a block
that contains a call.
--
Alan Modra
Australia Development Lab, IBM
