[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8420 - trunk/libavcodec/dv.c

Rich Felker dalias
Mon Mar 26 16:03:01 CEST 2007


On Mon, Mar 26, 2007 at 06:24:59AM -0700, Trent Piepho wrote:
> > Typical gcc propaganda-language documentation... In reality regparm is
> > not used (totally nonstandard ABI) and thus the scratch register for
> > prologue is irrelevant. I suspect the overhead is 2-3 opcodes, making
> > it irrelevant for the large sorts of functions that need aligned stack
> > variables. Or... does this option generate the (useless) prologue even
> > in functions that don't want or need the alignment?
> 
> It's a little more complex than that.
> 
> First, regparm _is_ used.  It's used by the Linux kernel by default.  It's

I'm talking about userspace apps of course, which need an ABI. Not
something self-contained like a kernel.

> also entirely possible to declare only certain internal functions regparm
> with function attributes, so it can still be used even through the ABI is
> non-standard.  regparm isn't an all or nothing proposition.

Yes, indeed.

> In fact, gcc can do this automatically for static functions.  It will
> inline them or call them with non-standard calling conventions if it thinks
> that will result in better code.

And what happens when you call these functions from inline asm??? All
hell breaks loose! Lovely, gcc....

> Secondly, using the stack re-alignment will typically cost an extra
> register for the entire function, not just the prologue.
> Normally, both the function's arguments and local variables can be
> addressed relative to ebp (or esp when using omit-frame-pointer).  When the
> stack is re-aligned, the function arguments are before the alignment while
> the locals are after the alignment.  They can't be addressed with the same
> register; it takes two.

As long as the number of arguments is small (normal) just copy them to
the new location.

> The purpose of the patch to gcc was to allow library or kernel entry points
> to be compiled with stack re-alignment.  gcc already had the ability to
> re-align main(), the patch just added this to other functions.  It does not
> automatically increase the stack alignment only as necessary when a
> function has stack variables that need greater than default alignment.
> That would be a nice feature, but it's not something gcc can do.  There is
> a phrase I've heard on this list, "patches welcome," that is apropos here.

Are you sure? Normally the gcc attitude is "our stuff is not broken
and we will not change it..."

Rich




More information about the ffmpeg-devel mailing list