https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #4)
> The change makes loop iteration estimates more realistics, but does not
> introduce any new code that actually changes the IL, so it seems this makes
> existing problem more visible.  I will try to debug what happens.

Yeah, I didn't see any debug info handling in that commit, so wouldn't surprise
me if it was something latent before, or something where ch now needs to do a
better job.
All I can see from the dumps is that before ch2 the debug stmt placements were
reasonable both for b and j, b 0 at the very start and after SSA_NAME def stmts
which update it to a new value for the var (e.g. after PHI at the start of loop
body,
or after increasing the IV).
Before r14-162 ch2 used to do weird stuff with them - duplicating
  # DEBUG b => 0
  # DEBUG b => 0
at the start, after ++j:
  # DEBUG j => j_9
  # DEBUG j => j_9
after ++b:
  # DEBUG b => b_7
  # DEBUG b => b_7
and (the perhaps only reasonable change adding
  # DEBUG j => 0
after the b PHI, though not really necessary as it has unconditional goto to
the header with PHI after which it is set to something else).
But, newly ch2 in addition to the useless duplicate of b => 0, j => j_9 and b
=> b_7
removes the most important debug stmts (
  # DEBUG j => j_2
and
  # DEBUG b => b_1
after the PHIs) and adds wrong-debug debug stmts elsewhere - the
  # DEBUG j => 0
and
  # DEBUG b => 0
in random incorrect places.

Reply via email to