[PATCH] final: Improve output for -dp and -fverbose-asm
Jeff Law
law@redhat.com
Fri Dec 1 00:26:00 GMT 2017
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
More information about the Gcc-patches
mailing list