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.