[PATCH] asm inline

Segher Boessenkool segher@kernel.crashing.org
Fri Oct 12 14:11:00 GMT 2018


On Fri, Oct 12, 2018 at 03:45:41PM +0300, Alexander Monakov wrote:
> On Fri, 12 Oct 2018, Segher Boessenkool wrote:
> 
> > The Linux kernel people want a feature that makes GCC pretend some
> > inline assembler code is tiny (while it would think it is huge), so
> > that such code will be inlined essentially always instead of
> > essentially never.
> 
> I do apologize for being quite late for the party here, but given
> that the main problem is too much of the asm body is accounted as
> its cost, wouldn't it be cleaner to give asm writers a way to
> write portions of asm template that GCC wouldn't count as its cost?
> 
> 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).

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

The inliner also uses this number (well, the estimated number of assembler
statments in fact, about the same as the number of machine instructions; not
the number of bytes taken by the code) to guide its decisions.  This is
pretty good in simple cases, but grossly wrong in other cases.

Making some parts of the asm template invisible to this counting does not
improve the estimated size very much IMO; my suggested solution is easier
to use, and cleaner (both in user code and in GCC code), and will result
in better results in the end I believe.


Segher



More information about the Gcc-patches mailing list