This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] asm inline
On Fri, Oct 12, 2018 at 07:57:12PM +0300, Alexander Monakov wrote:
> > 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.
The compiler estimates the size of an asm for very different purposes than
for making inlining decisions. It is pretty good for those other purposes,
but not great for inlining decisions. Your proposal makes it not good for
*either*, has a handwavy definition that is hard to reason with, and has
other problems integrating with the existing GCC code as well.
Don't focus on how to implement this. That is the easy part. Focus on how
to define the actual exact semantics of it, and how it interacts with other
inline assembler features, and what it will mean for later changes to
nearby code.
Also prototype code actually using it. See if there are unexpected
problems, if you can always predict what the behaviour will be, if it is
easy to get the behaviour you want. Also see if there would be easier
ways to get equivalent results.
Segher