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

[Rich Felker]

On Mon, Mar 26, 2007 at 08:22:27AM -0700, Trent Piepho wrote:
> > > 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.

All the ones regarding calling convention, yes... Forgive my bias, but
I'm really sick of gcc optimizing like this at all. It gives
inconsequential performance benefit, at the expense of all sorts of
bugs and headaches like this and (worse yet) at the expense of
superlinear growth of gcc bloat and compiletime slowness.

> Maybe this attribute or the noinline attribute disable optimizing the
> calling convention?

Would be nice, but I doubt it. I suppose the function name (i.e.
pointer) should just be passed as a constraint to the asm, if it's
possible to setup a call like that via inline asm semantics without
resorting to wasting a register storing the address..

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

Making functions with a variable number of arguments is mostly for
printf-type interfaces. I can't imagine why you'd want to use them in
a function with SSE-aligned buffers.. Making function calls with large
numbers of arguments is stupid in performance code anyway. You should
instead pass a single pointer to a context structure.

> How will debugging work, with the arguments moving from one
> place to another?

It won't care after the prologue code finishes.

> Is all this really going to be faster than just keeping
> the stack 16-byte aligned?

The question is not valid because there is no choice. The stack cannot
be kept aligned without a new ABI, which is outside the scope of gcc
and of developers like us. Setting the ABI is the sole responsibility
of the platform/system implementation.

Moreover, in the common case where you're not using SSE code, 16 byte
alignment will hurt performance by increasing memory usage. It spreads
data out across more cache lines due to padding. All of this to
micro-optimize a particular special case of SSE computation...

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

OK, this is informative. Thanks!

Rich