[FFmpeg-devel] [PATCH] AAC: type puns for 16 bit floating point rounding

[Uoti Urpala]

On Thu, 2008-12-04 at 14:22 +0000, M?ns Rullg?rd wrote:
> Uoti Urpala wrote:
> > On Thu, 2008-12-04 at 09:35 +0000, M?ns Rullg?rd wrote:
> >> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
> >>
> >> > On Thu, 2008-12-04 at 03:13 +0000, M?ns Rullg?rd wrote:
> >> >> Are this things safe under strict aliasing rules?
> >> >
> >> > Yes GCC does guarantee that it will work (all the accesses use
> >> > unionvalue.field syntax with the same union).
> >>
> >> What gcc does is irrelevant.  Is it guaranteed by the C standard?
> >
> > The GCC behavior is more relevant than the standard in this case. The
> 
> That is only true in the reverse situation, i.e. when the standard allows
> something but gcc misbehaves.  Then we have no choice but avoiding the
> offending construct.  If gcc happens to generate intuitively correct
> code for something that is undefined by the standard, we should still not
> be using that something.

It's not that GCC "happens to" generate the correct result, but that it
explicitly defines it will work.

> > standard won't guarantee that any such type punning code works anyway.
> 
> Then we should not be using it.

FFmpeg is using a lot more nonstandard stuff like asm for optimizations.
It also relies on other compiler-defined behavior in normal code.

>   There is no telling what another compiler
> or a future version of gcc might do.

You can tell with reasonable certainty. GCC has explicitly defined that
it will work. If you don't rely on that then you shouldn't rely on other
compiler-defined behavior either (like right shifting negative numbers,
or casting unsigned to signed to get a negative result). You have to
assume some sanity from any future compiler.

> > The reliability of such optimizations has to be determined based on the
> > probability that it will work in practice.
> 
> Writing code based on probabilities that it will work is bound to fail
> sooner or later.

Didn't you just advocate assuming that the platform is using IEEE754
float representation?

>   If there is any chance at all that it might fail, it
> should not be done.

Then you'll get nothing done.

> > GCC has the strictest aliasing requirements
> 
> What are you comparing it with?

Other compilers.

> > and it seems unlikely that some compiler would use more strict ones in
> > the future
> 
> Upon what do you base this assertion?

Disallowing that would break even more code than the GCC introduction of
strict aliasing did, it's desirable to have some supported mechanism for
type punning, and disallowing it is unlikely to allow any significant
optimizations.

> > (and if some compiler will use a significantly stricter interpretation
> > of the standard then other parts of FFmpeg will likely fail to compile
> > correctly too, this one being an easy one to diagnose and fix).
> 
> If this is the case, we should be fixing those parts, not adding more.

If you want to make optimizations more "reliable" then asm would be a
better place to start. For example there's lots of asm in FFmpeg that
fails to declare SSE register clobbers even though GCC can and does
itself generate code using those registers. Fixing this would require
splitting files and changing the build system, as GCC doesn't support
the register names at all unless the corresponding instruction set is
enabled (so all code using SSE registers would have to be in separate
files that would require -msse or higher to compile on 32-bit).