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

[Jeff Law <law@redhat.com>]

On 11/30/2017 10:55 AM, Martin Sebor wrote:
> 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.
FTR the number the instruction is the  insn's UID :-)

Also note that whether or not an instruction has a human readable
mnemonic is dependent on the target -- many don't have names for the
bulk of their insns or the names are fairly cryptic.

Ultimately fully understanding that data will always require a fairly
good understanding of GCC and the target.

> 
>> 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).
It's *supposed* to be bytes.  However, some targets may not have made
the conversion from instructions to bytes.

Jeff