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. Segher