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

[Måns Rullgård]

Uoti Urpala wrote:
> 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.

Same thing.  GCC happens to define this one way.  Another compiler may do
it differently.  GCC is not the only compiler.  BTW, where is such
behaviour of gcc documented?

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

Inline asm is used only with gcc and other compilers supporting the gcc
syntax.  Using a documented extension is very different from relying
on non-standard, documented or not, behaviour for normal code.

> It also relies on other compiler-defined behavior in normal code.

Where?  If possible, it should be identified and fixed.

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

I endeavour not to.

> (like right shifting negative numbers,
> or casting unsigned to signed to get a negative result).

As I said before, that excludes some Cray systems.

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

No.  I suggested making it configurable, so we can disable it for any
platforms we discover to use other representations.

>> If there is any chance at all that it might fail, it should not be done.
>
> Then you'll get nothing done.

There will of course always be mistakes, and we can never be sure we've
corrected them all.  However, we can make a good effort to avoid things
we *know* to be undefined.

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

Which ones?

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

Try for a moment to not see gcc as the centre of the universe.  Until
you've tested *every* compiler, you simply cannot say what works and
what doesn't.

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

This is definitely something that should be looked into.  I've seen
sloppy constraints or clobber lists break things with new gcc versions
too many times.

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

Not at all.  A few simple macros should be enough.

-- 
M?ns Rullg?rd
mans at mansr.com