https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |vmakarov at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I doubt the trigger is exactly CONCAT/CONCATN, I don't see those mentioned
anywhere in
the scheduler nor in i386 backend code related to scheduling.
But the DEBUG_INSN with CONCATN in this case contains 16 MEMs, perhaps
something defers some insns for later if that DEBUG_INSN is scheduled.
Not very familiar with the scheduling dumps though.
With:
./xgcc -B ./ -S -O2 -fsched2-use-superblocks -fcompare-debug pr106746.c
-Wno-psabi --param min-nondebug-insn-uid=10000 -fdump-tree-all -da
-fsched-verbose=8
I see that it is tick 24 in which insn 10148 is scheduled with -g0 and not
otherwise,
already in tick 21 it is:
;; 21--> 10090 xmm7=[dx*0x4+sp+0x8]
:hsw_decodern,hsw_p23
+;; dependencies resolved: insn 10148
+;; tick updated: insn 10148 into ready
;; dependencies resolved: insn 10203
;; tick updated: insn 10203 into ready
;; dependencies resolved: insn 10202
;; tick updated: insn 10202 into ready
;; dependencies resolved: insn 10201
;; tick updated: insn 10201 into ready
But why, I'm not sure.
