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
