[FFmpeg-devel] [PATCH 4/7] Use alias-safe types in AV_[RW] macros

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Fri, Jan 29, 2010 at 03:43:08AM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Fri, Jan 29, 2010 at 02:12:11AM +0000, Mans Rullgard wrote:
>> >> ---
>> >>  libavutil/intreadwrite.h |   14 +++++++-------
>> >>  1 files changed, 7 insertions(+), 7 deletions(-)
>> >
>> > id like to see some benchmark done with the latest gcc release
>> > and h264/h263/aac decoding as well as mpeg4 encoding on x86_64 (codecs
>> > randomly picked based more on what is used alot than what uses alot of funny
>> > accesses)
>
> ping

Decoding time (i7, gcc-4.4.3) with new macros divided by time w/o
(lower is better), best of five runs:

cathedral.mp4                         0.97    h264
indiana_jones_4-tlr3_h640w.mov        0.97
NeroAVC.mp4                           0.95
IronMan.mkv                           0.94
NeroRecodeSample.mp4                  0.99    mpeg4
broken-ntsc.mpg                       0.99    mpeg2
yeah.mpg                              1.00
Lumme-Badloop.ogg                     0.94    vorbis
When_I_Grow_Up.flac                   1.02
Silent_Light.mp3                      1.00
Canyon-5.1-48khz-448kbit.ac3          1.00
lotr_5.1_768.dts                      1.00
red_red_wine.aac                      0.99
walk_like_an_egyptian.wma             1.01

The audio files are decode so quickly that it's hard to get good
numbers.  Run-to-run variations are greater than any difference
between the two builds.

I don't have ready scripts for mpeg4 encoding.

>> > if nothing gets slower then iam not against this otherwise i think
>> > more investigation is needed
>> >
>> > Also how does this stuff interact with restrict ?
>> > Which overrides the other? can we still use restrict to make sure the
>> > gcc is aware that aliasing does not happen?
>> 
>> This is the opposite of restrict.  Qualifying a pointer with restrict
>> informs the compiler that aliasing will *never* happen even with the
>> normal type rules would allow it.  This is to be used in cases where
>
> i know that, my question was if restrict overrides av_alias or av_alias
> restrict?

Using both on the same pointer seems rather weird, and I don't know
what happens in that case.  If used on different pointers, I guess the
av_alias one is assumed to aliasing something while the restrict one
is not.  Nothing really ambiguous there.  Writing to memory addressed
by a restrict-pointer through another pointer is probably a bad idea.

>> we *intentionally* violate the basic aliasing rules.  This is causing
>> actual errors with some compilers on some targets.
>
> we do violate them and i dont doubt that some compilers generate non
> functional code. It does not mean though these 2 are related.

Sorry, I don't follow.

> also the C standard defines a solution via unions, i do not understand
> why may_alias is needed. You can just have an union of a packed struct
> and a second type to indicate posible aliasing between them i think.
> (this requires fewer non standard attributes)

According to Jason, gcc seemed to require those attributes in some
cases even with the unions.  Ask him for details.

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