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

[Uoti Urpala]

On Thu, 2010-02-18 at 16:16 +0000, M?ns Rullg?rd wrote:
> 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:
> >> > 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

Not really "opposite". It only says that aliasing can not be determined
based on type.

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

I think there wouldn't be anything weird about that. One example that I
think would be natural is as follows: setup code first initializes data
by writing as one type, and then there's an inner loop that uses
restrict for optimization (it can't alias other pointers in the inner
loop) and the macro to indicate that it reads data that was written as a
different type.

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

There's no problem with such writes if the other pointers are based on
the restrict one. So code like this is OK:
uint16_t * restrict p = &(uint16_t){12345};
*p++;
char *p2 = p;
*p2 = 1;
return *p;

It sounds like you have an inaccurate view of what "restrict" really
means. It doesn't say "no other pointer will ever point at the same
thing". The most basic meaning is "treat this pointer as if it was just
initialized with 'p = malloc(100);' - nothing older can point there" (of
course this is not a full description). Using the macros with a restrict
pointer, or one based on that pointing to the same memory, is not
necessarily any "weirder" than using them on memory that the compiler
can see was just allocated.

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

My understanding is that if GCC sees something is declared as "int
a[1000];" - as in "real" type of the underlying object, not just pointer
types used with malloc()ed memory and such - then it refuses to believe
anything of a different type could alias that, not even unions or
structs that contain one int only. With allocated memory it can't tell
whether the "real" type of the object is an int or an union containing
an int.