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

Måns Rullgård mans
Thu Dec 4 15:22:24 CET 2008


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:
>> >> > @@ -838,24 +842,45 @@ static int decode_spectrum_and_dequant(AACContext
>> * ac, float coef[1024], GetBit
>> >> >  }
>> >> >
>> >> >  static av_always_inline float flt16_round(float pf) {
>> >> > +#ifdef ENABLE_IEEE754_PUN
>> >> > +    union float754 tmp;
>> >> > +    tmp.f = pf;
>> >> > +    tmp.i = (tmp.i + 0x00008000U) & 0xFFFF0000U;
>> >> > +    return tmp.f;
>> >> > +#else
>> >>
>> >> 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.

A lot of "bugs" reported against gcc 4.3 are in fact the result of new
optimisations exposing reliance on undefined behaviour.

> standard won't guarantee that any such type punning code works anyway.

Then we should not be using it.  There is no telling what another compiler
or a future version of gcc might do.

> 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.  If there is any chance at all that it might fail, it
should not be done.

> GCC has the strictest aliasing requirements

What are you comparing it with?

> and it seems unlikely that some compiler would use more strict ones in
> the future

Upon what do you base this assertion?

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

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




More information about the ffmpeg-devel mailing list