--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-21 14:16 ---
I think there are two problems in reorder_blocks{,_1}:
1) BLOCK_FRAGMENT_CHAIN should be reversed on each block when reorder_blocks_1
finishes, otherwise the chain starts with the earliest fragment
(BLOCK_FRAGMEN
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-21 13:26 ---
Found a problem - the patch relies on the fact that the fragments of each block
are sorted in ascending order of their PCs, but apparently that is not the
case. So how much the patch will actually save on .debug_loc si
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-20 15:33 ---
That hoisting/sinking is usually marked with that BLOCK from which it has been
sunk or hoisted. And even if not, no debug info consumer I'm aware of will
tell you anything about the variables that are not in the scope
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-20 14:04 ---
But we can end up hoisting/sinking scalar code outside of the lexical block
of variable uses. I think a better approach would be to limit the locations
to regions that overlap lexical block + life range.
--
htt
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-19 21:50 ---
Similar effects on x86_64 cc1plus:
before:
DW_AT_location count 312834, cc1plus size 83M
[28] .debug_info PROGBITS 10eb517 149edb3 00
0 0 1
[32] .debug_locPROGBITS
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-19 20:56 ---
The patch has been bootstrapped/regtested on x86_64-linux and i686-linux and
apparently has huge effect on the debug info size.
i686 cc1 before:
DW_AT_location count 305862
[28] .debug_info PROGBITS000
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-19 16:38 ---
Created an attachment (id=20142)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20142&action=view)
gcc45-pr43442.patch
Untested patch that cures the size of .debug_loc on the reduced pr43058.c
testcase even witho
