This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Confusing fall through BB pc in conditional jump
Hi Kewen,
On Fri, Jun 28, 2019 at 09:56:58AM +0800, Kewen.Lin wrote:
> > It's probably a good idea to spend a line on this even in slim mode, it's
> > really easy to miss and get confused and waste time without it. Nice :-)
> >
> >> The dumping will look like:
> >> 6: NOTE_INSN_BASIC_BLOCK 2
> >> ...
> >> 12: r135:CC=cmp(r122:DI,0)
> >> 13: pc={(r135:CC!=0)?L52:pc}
> >> REG_DEAD r135:CC
> >> REG_BR_PROB 1041558836
> >> ;; pc (fall through) -> L67
> >> 31: L31:
> >> 17: NOTE_INSN_BASIC_BLOCK 3
> >
> > I think it should say the BB number it falls through to. Is the label
> > number (insn number) useful? Maybe the BB number isn't always printed
> > in slim dumps?
>
> OK, to use the label was meant to keep the same as what we print for jump
> targets of jump insn. Yes, I think it's better to use BB number.
> I think we can get the BB number from NOTE_INSN_BASIC_BLOCK now, it's
> always printed in slim dumps.
Ah cool. I don't often look at "normal" slim dumps, sorry if some things
I said were more confusing than helpful :-) (I see the thing combine
prints at the start of the dump a lot, but that skips all non-insns. I
should change that to make BB boundaries visible, it's pretty crucial for
combine :-) )
> > Maybe slim dumps should always spend a line on showing basic block
> > boundaries? Something visual like maybe
> > ; ------------------------------
> > or
> > ; BB 456 ------------------------------
> > or
> > ; ------------ falls through to BB 123
> > or
> > ; ------------ falls through to BB 123
> > ; BB 456 ------------------------------
> >
>
> It seems the current NOTE_INSN_BASIC_BLOCK is enough for the beginning?
Yes, you are right. That note itself is probably enough to make it obvious
there is a BB boundary, when skimming a dump.
> > I don't use slim dumps much, they lose too much information, but maybe
> > that can be fixed :-)
>
> OK, since I haven't got used to lisp format, the slim seems more
> understandable to me. If it's not used too much, maybe this confusion
> and possible improvement is too trivial. :)
Slim dumps are much more compact, so you can do some things with it that
you cannot with "full" dumps. But they miss just a little bit *too* much
information; your patch helps to fix that. I'm all for it :-)
[ Unrelated... One of my biggest problems with slim dumps... subregs...
If it says
r128:CC=cmp(r124:DI#4,0)
then in what mode is the compare actually done? Now because I know what
target this is in which configuration, the #4 is a good hint it is SImode,
but what if it was LE so it would say #0? And for some ops you really
cannot guess at all, say when picking apart a register. ]
Segher