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

[Jeff Law <law@redhat.com>]

On 11/30/2017 03:54 PM, Martin Sebor wrote:
> On 11/30/2017 10:07 AM, Segher Boessenkool wrote:
>> On Thu, Nov 30, 2017 at 09:54:26AM -0700, Martin Sebor wrote:
>>>> It is neither line length nor amt of info that makes the second one
>>>> way better readable.
>>>
>>> The justification certainly makes it easier to read.  But
>>> the abbreviations make it harder to interpret.  [c=4 l=4]
>>> makes no sense to anyone not already familiar with what
>>> it means.
>>>
>>> There's nothing wrong with using mnemonics as long as they're
>>> well established and commonly understood.  Absent that, they
>>> should be explained in some accessible document.
>>>
>>> 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.
>>
>> This is the -dp output, I hardly ever use -fverbose-asm, it has been
>> unreadable for ten years or so.
>>
>> -fverbose-asm looks like this:
>> ===
>> .L.yk:
>>  # 81288.c:4:   unsigned int *un = (f3 != 0) ? &t4 : 0;
>>         cmpdi 0,4,0      # tmp130, f3
>>         beq 0,.L2        #
>>  # 81288.c:6:   *un ^= t4;
>>         srdi 9,3,32      #, tmp131, t4
>>         xor 9,9,3        #, tmp132, tmp131, t4
>>  # 81288.c:7:   if (*un == t4)
>>         rldicl 9,9,0,32  # tmp133, tmp132
>>  # 81288.c:7:   if (*un == t4)
>>         cmpd 7,9,3       # t4, tmp134, tmp133
>>         beq 7,.L7        #
>> .L5:
>>  # 81288.c:11: }
>>         mr 3,4   #, <retval>
>>         blr
>> .L2:
>>  # 81288.c:6:   *un ^= t4;
>>         lwz 9,0(4)       # MEM[(unsigned int *)0B], _13
>>         trap
>> .L7:
>>  # 81288.c:8:     f3 = !!t4;
>>         addic 4,9,-1     # tmp139, tmp133
>>         subfe 4,4,9      # <retval>, tmp139, tmp133
>>         b .L5    #
>> ===
>>
>> If we're okay with outputting that kind of stuff to *users*, then how
>> bad is [c=8 l=4] for GCC developers?  Heh.
> 
> I don't know if the above is okay or not.  What I do know is
> that [l=4] is not an improvement over [length = 4].
It can be if the lines are getting long enough to wrap.

> 
> But I think there are ways to improve the readability while
> at the same time making the output more compact.  I mentioned
> documenting the labels (whatever they may be) in the manual
> as one possibility.  Another idea is to print a brief legend
> at the bottom of the file explaining what l= stands for.  Yet
> another is to print a header at the top of every function with
> a label for each column (like in the top command), and then
> document what each column means in the manual by referring
> to the column headers.  I'm sure there are others.
And I think these could all move forward independently.

jeff