On Tue, 2007-11-06 at 00:15 -0800, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
> >
> > > One example of where it hurts on just about any platform is something
> > > like this:
> > >
> > > void allocate(int **p, unsigned len);
> > >
> > > int *foo(unsigned len) {
> > > int *p;
> > > unsigned i;
> > > allocate(&p, len);
> > > for (i = 0; i < len; i++)
> > > p[i] = 1;
> > > return p;
> > > }
> The assignment is indeed of an int, but it uses a pointer. Strict
> aliasing only refers to loads and stores which use pointers. The
> type-based alias analysis is done on the types to which those pointers
> point.
>
> Given two pointers, "T1* p1" and "T2* p2", type based alias analysis
> (aka strict aliasing) lets us conclude that p1 and p2 point to
> different memory if T1 and T2 are incompatible types with respect to
> aliasing. The rules for alias compatibility come straight from the C
> standard.
Yes but I still don't understand. The claim was that the assignment
might modify p. This is is contra-indicated since p is a pointer
to an int, whereas the value being assigned is an int.
So IF we assume an int cannot alias a pointer, p cannot be modified:
the only store is of a type which cannot modify p.
This assumes we apply aliasing rules EXCEPT between pointers.
In particular, let me try to build a model: partition all the
types into classes which can alias each other, in two ways:
with strict aliasing (S), and with rough aliasing (R).
Then in S, T1* and T2* can alias IFF T2 is T2 (except for 'void'
of course).
Whereas in in R, T1* and T2* can alias each other independently
of T1 and T2.
However in R, int cannot alias T1*. So the assignment of an int
cannot modify p above in EITHER partition S or R.
[Yes, I know it probably isn't a partition, just a mental model]
Now of course if we allow int to alias a pointer, THEN certainly
the assignment may modify p (at least without data flow analysis
to prove otherwise we have to assume that).
However this is a different circumstance. My understanding
was that gcc with strict aliasing turned off would optimise
the code above the same way as if it were on. On amd64
an int cannot alias a pointer (int is 32 bits, pointer is
64 bits).
So I remain confused as to the difference between strict
and non-strict aliasing with respect to what optimisations
are permitted (and/or actually done).
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
