This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] final: Improve output for -dp and -fverbose-asm
- From: Jeff Law <law at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 30 Nov 2017 17:26:54 -0700
- Subject: Re: [PATCH] final: Improve output for -dp and -fverbose-asm
- Authentication-results: sourceware.org; auth=none
- References: <ac47cf30cab2820e22831de664d8d42964705d88.1511996668.git.segher@kernel.crashing.org> <95ff7e21-ca49-b714-cd17-632a30fffb61@gmail.com> <20171130111644.GY10515@gate.crashing.org> <2393c7a7-60a9-29fd-4d0c-49523734201d@gmail.com> <20171130164425.GB10515@gate.crashing.org> <dbbf5199-96cf-9d25-6711-eaedccf27c18@gmail.com> <20171130170724.GC10515@gate.crashing.org> <53eb6162-a9c9-ed2f-c3dc-85bc38bf29fd@gmail.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