[FFmpeg-devel] [PATCH 4/7] Use alias-safe types in AV_[RW] macros
Thu Feb 18 17:16:17 CET 2010
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)
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
NeroRecodeSample.mp4 0.99 mpeg4
broken-ntsc.mpg 0.99 mpeg2
Lumme-Badloop.ogg 0.94 vorbis
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
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.
mans at mansr.com
More information about the ffmpeg-devel