[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8420 - trunk/libavcodec/dv.c
Mon Mar 26 17:22:27 CEST 2007
On Mon, 26 Mar 2007, Rich Felker wrote:
> > 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....
For pretty much any optimization gcc could make, one could write asm code
that will break because of it. gcc will often inline static functions and
not even emit the code for them. Calling functions from asm isn't very
common, and there are work-arounds, e.g. don't make the function static or
call the function through a function pointer. There is also this
This attribute, attached to a function, means that code must be
emitted for the function even if it appears that the function is not
referenced. This is useful, for example, when the function is
referenced only in inline assembly.
Maybe this attribute or the noinline attribute disable optimizing the
> > 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.
But what if they're large? What about functions with a variable number of
arguments? How will debugging work, with the arguments moving from one
place to another? Is all this really going to be faster than just keeping
the stack 16-byte aligned?
> > 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..."
You can find discussions of this on the gcc list. There are messages from
developers who think re-aligning all functions is very expensive, that it's
a bug to not produce a warning/error when a stack variable needs alignment
greater than the stack alignment, and that it would be nice to be able to
re-align a function's stack only when it needs it, and no one disagreeing
with those statements.
I can't find anything where someone provided a patch to do what you've
talked about and it was rejected.
More information about the ffmpeg-devel