Re: [PATCH] final: Improve output for -dp and -fverbose-asm

[Martin Sebor <msebor@gmail.com>]

On 11/30/2017 10:02 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 30 Nov 2017, Martin Sebor wrote:
>
>>>         addic 4,9,-1     # 70   [c=4 l=4]  *adddi3_imm_carry_m1
>>>         subfe 4,4,9      # 71   [c=4 l=4]  *subfdi3_carry_in_internal
>>>         b .L5            # 81   [c=4 l=4]  jump
>>
>> Not everyone who reads the verbose assembly is familiar with
>> GCC internals.  Users read it to help debug problems in their
>> code.  They shouldn't have to also study GCC source code to
>> understand what the contents mean.
>
> Um, I think that's a bit overactive.  How would you know what
> adddi3_imm_carry_m1 really means without knowing the particular GCC
> backend?  Or what the above magic number after # means?

adddi3_imm_carry_m1 seems (mostly) self-explanatory since it's
built up of common assembly mnemonics.  I confess I don't know
what the number after # means, either on powerpc64 or on any
other target.  I'd say that just shows that not even full time
GCC developers are (or can be expected to be) familiar with all
GCC internals, and we shouldn't need to study the back end code
to interpret basic things like # 7 in the output.

> Or, for that matter, what "length" means?  Could be byte-length, sure.
> But OTOH, for a RISC target it's always four, so why print it?  The GCC
> developers surely meant cycle-length with that, nothing else makes sense.

Heh.  I thought it meant the length of the instruction in bytes,
and it made perfect sense to me.  Sounds like I misinterpreted it.
Which suggests that it should be mentioned in the manual (whatever
label it ends up with).  With it documented (and the position on
the line made clear), the length= or l= part could even be skipped
altogether to save a few more bytes if that's important (I don't
think it is in this case).

> My point is, to interpret the asm dumps there's no way around having some
> knowledge and getting used to it.  In addition I doubt they're used
> heavily to debug programs.  Rather they're used to study the interaction
> between compiler and program (and potentially to find miscompilations or
> strangenesses the compiler emits).  As such even -fverbose-asm is a
> low-level compiler debugging tool, not something for an end-user that
> needs stability or documentation.

Sure, basic knowledge of the target assembly is prerequisite.
That includes some familiarity with common mnemonics.  But
except for details whose purpose is to expose GCC internals,
knowledge of GCC implementation details (or having to read
GCC source code that prints this stuff) shouldn't be.

The basic point I'm making is that shortening length=NN to l=NN
is not an improvement to the readability of the output and is
contrary both to the documented purpose of the -fverbose-asm
option and Segher's objective for the patch.  The convention
used in the output is to use mnemonics, similar to the assembly
code itself.  One letter mnemonics aren't nearly as effective
as those consisting of multiple letters.  Does l stand for load,
length, latency, or something else?  That's why they are almost
mever used.  In contrast, ld is a known mnemonic for load, len
for length, and lat(?) could with some effort be correctly
interpreted as latency.

This seems fairly elementary to me and I would have expected
it to be non-controversial so I'm not sure why it's being
challenged.  Don't we want the output to be generally useful?
What do we gain by adopting these terse abbreviations?

Martin