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

[Rich Felker]

On Sun, Mar 25, 2007 at 11:43:40AM +0100, M?ns Rullg?rd wrote:
> Rich Felker <dalias at aerifal.cx> writes:
> 
> > On Sat, Mar 24, 2007 at 09:17:47PM -0700, Roman Shaposhnik wrote:
> >> > it's a matter of what the calling
> >> > code does. Thus all you can ever assume on x86 is 4. In order to be
> >> > correct, the compiler must generate code to fully align the stack in
> >> > any function that depends on the stack being aligned. gcc does not do
> >> > this, so it's broken. Either they should fix this or document the fact
> >> > that alignment attributes do not work on automatic variables.
> >>  
> >>   In Sun Studio compilers we've decided to do a combined approach
> >> now -- we honor requests for alignment of the automatic variables 
> >> up to the ABI requirements (although, it seems to be safe to assume
> >> 8 on Pentium+ these days for obvious reasons) and we issue a warning
> >> if the requested alignment is higher. I believe it was suggested that
> >> gcc guys do the same -- but they don't seem to be interested.
> >
> > I hope you only assume 8 if -march=586 or similar is used. I always
> > build with vanilla i386 except for really rare cases like mplayer.
> 
> No wonder you're complaining about things being slow.

-march gives at most a 1-5% increase in performance, which is useless
in anything except a movie player or action game or similar realtime
app. Also the programs that most need performance are the ones where
it helps least, since they've already had the critical parts written
in asm.

I really don't think it helps for the 1% of /bin/ls spent in userspace
to be 1% faster... On the other hand, it's been quite nice being able
to swap drives into ANY i386 hardware when I had sudden hardware
failure, which would not have been possible if I'd uselessly built
everything with -march. Thus I'll continue to build everything but
ffmpeg/mplayer as plain 386 code, and flame the gentoo ricers with
their 100+ character CFLAGS...

> > Most likely alignment doesn't matter for pre-586 anyway, but I suppose
> > someone could be using it for evil hacks like storing extra data in
> > the low bits of pointers... :)
> 
> Lisp interpreters tend to do such things.

Yes, I was thinking of emacs.. :) However it only uses global static
objects and malloc, none on the stack. The problem would go away
anyway if they just stored the type of the lisp object as the first
word pointed to, instead of trying to store it in the pointer itself.
No one really cares about one wasted word per object...

Rich