12:13 a.m.
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
int f() {
a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the
one most recently written to (called "type-punning") is common.
Even with `-fstrict-aliasing', type-punning is allowed,
provided the memory is accessed through the union type. So, the
code above will work as expected. However, this code might not:
int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
This looks insane. Am I misreading it, or does it really say that
`*(&t.i)' is different than `t.i'? Also, why should union type
variables be any different than other variables in this regard? For
instance:
int f() {
int a;
int *ip;
a = 10;
ip = &a;
return *ip;
}
How is this any different than what is done above?
"everybody has fixed their code already because other compilers
have
been doing this optimization for ages"
If the last is really the case, then we indeed have nothing to worry
about. XEmacs has compiled and run on non-Gcc compilers for ages.
*If* the last is really the case.
5:03 a.m.
New subject: dealing with strict aliasing rules
My memory says that somebody (Valdis?) reported crashes with the
AIX compiler at high optimization because it started assuming
that pointers were not aliased. The optimization (I guess) is
that a value does not ever have to hit memory if the compiler can
determine that no pointer could ever reference it. The value can
live entirely in a register, which is a win.
This looks insane. Am I misreading it, or does it really say that
`*(&t.i)' is different than `t.i'? Also, why should union type
variables be any different than other variables in this regard? For
instance:
I think they are saying that *((int *)&t.d) is not equal to
*(&t.i). To make it possible for the int value and the floating
point value of the union to live in two different registers, the
compiler writers demand that you explicitly ask for type-punning so
they can only do the expensive memory store when necessary.
To try and answer Hrvoje's question, which was roughly "What is the
difference between these two functions?"
int f() { int f() {
a_union t; int a;
int* ip; int *ip;
t.d = 3.0; a = 10;
ip = &t.i; ip = &a;
return *ip; return *ip;
} }
In the function on the left the optimizer will see that there is
no pointer reference to t.d. &t.i, not &t.d, is copied to ip.
t.d and t.i don't necessarily share storage space unless you
reference the union element directly. Sort of like quantum
states being unresolved until you look at them. So 3.0 never
has to be copied from a register to memory.
In the function on the right, &a is copied to ip. ip is later
dereferenced, so the register contents need to be in memory before
that dereference happens. (ip should really be declared "volatile
int *ip" to keep the ip assignment and subsequent deference from
being optimized away.)
7:17 a.m.
New subject: dealing with strict aliasing rules
On Wed, 16 Jun 1999, Kyle Jones wrote:
To try and answer Hrvoje's question, which was roughly "What
is the
difference between these two functions?"
> int f() { int f() {
> a_union t; int a;
> int* ip; int *ip;
> t.d = 3.0; a = 10;
> ip = &t.i; ip = &a;
> return *ip; return *ip;
> } }
In the function on the left the optimizer will see that there is
no pointer reference to t.d. &t.i, not &t.d, is copied to ip.
t.d and t.i don't necessarily share storage space unless you
reference the union element directly. Sort of like quantum
states being unresolved until you look at them. So 3.0 never
has to be copied from a register to memory.
I don't think I understand that. t.i and t.d do share the same memory
space. Since the address of t.i is taken, the compiler must ensure that
at all "places that matter" (function calls, dereferences, etc), that t.d
and t.i are "flushed" to memory, since they occupy the same bits.
A clever optimizer may be able to save the memory store, but it would have
to know how to slice a double into an int. [Remember that f() does not
return 3, but the upper/lower 2/4/8 bytes of the double.]
In the function on the right, &a is copied to ip. ip is later
dereferenced, so the register contents need to be in memory before
that dereference happens. (ip should really be declared "volatile
int *ip" to keep the ip assignment and subsequent deference from
being optimized away.)
Why bother? Let the optimizer do its best:
int f() {
int a;
int *ip;
a = 10;
return *(ip = &a);
}
"ip isn't used again. Don't store."
return *&a
"I know that *&a == 10 in all cases"
int f() {
int a;
a = 10;
return 10;
}
"a is set without side effects optimize it away, and unused again" =>
int f() {
return 10;
}
-Justin
vallon(a)mindspring.com
9:56 a.m.
New subject: dealing with strict aliasing rules
Justin Vallon writes:
On Wed, 16 Jun 1999, Kyle Jones wrote:
> To try and answer Hrvoje's question, which was roughly "What is the
> difference between these two functions?"
>
> > int f() { int f() {
> > a_union t; int a;
> > int* ip; int *ip;
> > t.d = 3.0; a = 10;
> > ip = &t.i; ip = &a;
> > return *ip; return *ip;
> > } }
>
> In the function on the left the optimizer will see that there is
> no pointer reference to t.d. &t.i, not &t.d, is copied to ip.
> t.d and t.i don't necessarily share storage space unless you
> reference the union element directly. Sort of like quantum
> states being unresolved until you look at them. So 3.0 never
> has to be copied from a register to memory.
I don't think I understand that. t.i and t.d do share the same memory
space. Since the address of t.i is taken, the compiler must ensure that
at all "places that matter" (function calls, dereferences, etc), that t.d
and t.i are "flushed" to memory, since they occupy the same bits.
Not with the new rules. Taking the address does not guarantee the
flush will happen. The reason the compiler can get away with it
is the union t has a storage class of auto. No legal pointers to
this object can exist outside the block so the compiler aoid the
flush confident that nothing is pointing to union's memory.
A clever optimizer may be able to save the memory store, but it would
have
to know how to slice a double into an int. [Remember that f() does not
return 3, but the upper/lower 2/4/8 bytes of the double.]
That's the reason for the 'similar types' exception in
[...] an object of one type is assumed never to reside at the
same address as an object of a different type, unless the
types are almost the same.
The compiler writers are willing to do punning where the two
objects could fit into the same sort of register. Otherwise
forget it.
> In the function on the right, &a is copied to ip. ip is
later
> dereferenced, so the register contents need to be in memory before
> that dereference happens. (ip should really be declared "volatile
> int *ip" to keep the ip assignment and subsequent deference from
> being optimized away.)
Why bother? Let the optimizer do its best:
I meant for the sake of the example, which falls apart otherwise.
7:46 a.m.
New subject: dealing with strict aliasing rules
On Wed, 16 Jun 1999 21:03:58 PDT, Kyle Jones <kyle_jones(a)wonderworks.com> said:
My memory says that somebody (Valdis?) reported crashes with the
AIX compiler at high optimization because it started assuming
that pointers were not aliased. The optimization (I guess) is
that a value does not ever have to hit memory if the compiler can
determine that no pointer could ever reference it. The value can
live entirely in a register, which is a win.
Yes, it was me. However, that was originally against 20.mumble, in
the pre-gung-ho days.
The actual optimization (at least as performed by IBM with -qansialias)
is to check that if we have a pointer 'struct foobar *fooptr', and another
pointer 'struct baz *bazptr', if code does the following:
x = fooptr->field1;
bazptr->somefield = mumble;
y = fooptr->field2;
then -qansialias tells the compiler that it's free to assume that
no load/store via bazptr will conflict with a load/store through
fooptr. Not only does this mean it may be able to optimize out a
store, but it also has implications for code migration (for instance,
if field1 and field2 are 2 adjacent fields, it can scoot the
assignmnet to Y up above mumble, use a register already contianing fooptr,
etc. I haven't been able to coerce XLC to use a 'load multiple'
to load both x and y in the same opcode, but it's conceivable ;)
If I remember correctly, the aliasing problems cropped up in alloc.c.
I was in the process of rebuilding to test, but I just realized that
(a) it's 2:30Am, and (b) as a result, I compiled with '-O3 -qstrict'
where 'strict' tells the optimizer to not get into massive code
optimizations that may have an impact on program logic (which probably
inhibits most optimizations that ansialias would allow).
/Valdis
9293
days inactive
9294
days old
4 comments
4 participants
participants (4)
-
Hrvoje Niksic -
Justin Vallon -
Kyle Jones -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks