On Thu, 2017-11-30 at 18:02 +0100, Michael Matz wrote: > Hi, > > On Thu, 30 Nov 2017, Martin Sebor wrote: > > > > addic 4,9,-1 # 70 [c=4 l=4] *adddi3_imm_carry_m1 > > > subfe 4,4,9 # 71 [c=4 > > > l=4] *subfdi3_carry_in_internal > > > b .L5 # 81 [c=4 l=4] jump > > > > 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. > > Um, I think that's a bit overactive. How would you know what > adddi3_imm_carry_m1 really means without knowing the particular GCC > backend? Or what the above magic number after # means? > > Or, for that matter, what "length" means? Could be byte-length, > sure. > But OTOH, for a RISC target it's always four, so why print it? The > GCC > developers surely meant cycle-length with that, nothing else makes > sense. > > My point is, to interpret the asm dumps there's no way around having > some > knowledge and getting used to it. In addition I doubt they're used > heavily to debug programs. Rather they're used to study the > interaction > between compiler and program (and potentially to find miscompilations > or > strangenesses the compiler emits). As such even -fverbose-asm is a > low-level compiler debugging tool, not something for an end-user > that > needs stability or documentation.
-fverbose-asm is on the border of compiler-debugging vs end-user usage. FWIW an improvement to -fverbose-asm was explicitly mentioned in the gcc 7 release notes: https://gcc.gnu.org/gcc-7/changes.html and I've seen at least some end-users comment favorably on that change; this was: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01051.html which was originally a "-fasm-show-source" option. Dave
