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

[Michael Matz <matz@suse.de>]

Hi,

On Thu, 30 Nov 2017, Martin Sebor wrote:

> 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.

insn uid.

> > 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.

It _does_.  My point was to show you that even lengthy (ahem) 
non-abbreviations are open to interpretation, and that it's not the number 
of characters that make the difference, but knowledge.  And perhaps, 
missing the latter, documentation.

> 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 I disagree.  It _is_ improving readability IMHO.  Basically the more 
often you need to mention token X, the shorter it can and should be.  If 
you mention something every line, it should be as short as possible, 
which is one character, and to give the eye some hold while scanning the 
line some visual punctuation like '=' should be added as well.

> as those consisting of multiple letters.  Does l stand for load,
> length, latency, or something else?

As context matters I think you're making up a problem that doesn't exist.

> 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?

Define "generally useful" in the context of -fverbose-asm.  I think it is 
already, and Seghers patch improves on this.

> What do we gain by adopting these terse abbreviations?

That OTOH seems obvious to me: lines that don't exceed terminal width.  
There's nothing more disturbing than line breaks in line-oriented formats 
like assembler.


Ciao,
Michael.