On 11/30/2017 10:55 AM, Martin Sebor wrote: > On 11/30/2017 10:02 AM, 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? > > adddi3_imm_carry_m1 seems (mostly) self-explanatory since it's > built up of common assembly mnemonics. I confess I don't know > what the number after # means, either on powerpc64 or on any > other target. I'd say that just shows that not even full time > GCC developers are (or can be expected to be) familiar with all > GCC internals, and we shouldn't need to study the back end code > to interpret basic things like # 7 in the output. FTR the number the instruction is the insn's UID :-)
Also note that whether or not an instruction has a human readable mnemonic is dependent on the target -- many don't have names for the bulk of their insns or the names are fairly cryptic. Ultimately fully understanding that data will always require a fairly good understanding of GCC and the target. > >> 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. > > Heh. I thought it meant the length of the instruction in bytes, > and it made perfect sense to me. Sounds like I misinterpreted it. > Which suggests that it should be mentioned in the manual (whatever > label it ends up with). With it documented (and the position on > the line made clear), the length= or l= part could even be skipped > altogether to save a few more bytes if that's important (I don't > think it is in this case). It's *supposed* to be bytes. However, some targets may not have made the conversion from instructions to bytes. Jeff
