On Fri, 12 Oct 2018, Segher Boessenkool wrote: > > For instance by introducing special tokens like %[ %] that demarkate > > portion of the asm that shouldn't be counted: > > This potentially conflicts with targetm.asm_out.print_operand_punct_valid_p > (and it does in fact conflict for microblaze).
As far as I can tell, microblaze.c:print_operand will handle it via default: output_operand_lossage ("unknown punctuation '%c'", letter); (as any non-letter punctuation other than ?@# ), so it seems unclear why the port claims it as valid. In any case, if we choose to pursue this solution at all, we should be able to find a workable delimiter style. > > The implementation on GCC side should be quite simple. > > I don't agree at all. Sure it is not very many lines to implement this, > but it will make the semantics of inline assembler even stranger than it > already is. > > I also don't think it will be very useful. > > The "count the number of instructions in an asm" thing in GCC is primarily > meant to generate *correct* code: if the asm does not do strange things > (assembler pseudo-ops, change object section, etc.), it can reliably count > an upper bound of the number of bytes this asm will take, and that matters > for things like keeping jump targets in range. Please consider that as currently GCC over-estimates length of such asms, branches around them are emitted as long-range jumps more often than needed, which should be a problem we'd want to solve, because the whole reason this is being raised is because such asms appear in hot code paths. My proposal solves this aspect as well. Alexander