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
