This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Pessimization
- To: drepper at cygnus dot com (Ulrich Drepper)
- Subject: Re: Pessimization
- From: John Carr <jfc at mit dot edu>
- Date: Tue, 19 May 1998 07:29:18 EDT
- Cc: egcs at cygnus dot com
> The real problem must have been deeper down in the code since Richard
> had similar problems with struct (!) on Alpha.
The alias code assumes that a struct at a variable address does not
overlap a scalar at a fixed address. gcc considers a union the same
as a struct (the comment in rtl.h which says MEM_IN_STRUCT_P is not
set for a union member appears to be wrong). There are at least two
problems with this code:
1. With stdarg there is no correlation between a store and a dependent
load. Mode, MEM_IN_STRUCT_P, and the form of the address may be
different. The alias code sometimes gets confused. These problems
can probably be fixed on a case-by-case basis.
2. Whether an address appears varying depends on optimizations. Code
like this may be incorrectly optimized:
struct x { int i; };
void *self(void *ptr) { return ptr; }
f1()
{
struct x x = { 3 };
int *ip = &x.i;
struct x *xp = self(&x);
*ip = 0;
return xp->i + 1;
}
After CSE, *ip is seen as a scalar reference at a fixed address.
xp->i is a struct reference at a varying address. The alias code
believes the expressions can not refer to the same memory, and based
on this information the scheduler may move the load from xp->i before
the store to *ip.
gcc2 may have the same bug. It passed my test case but I think that
is due to other code generation differences.
I had left the struct/varying test disabled until the alias code could
be rewritten. Jim Wilson said he believed failure due to this bug is
sufficiently rare that the optimization is worth the risk.