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
