This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Pessimization
- To: John Carr <jfc at mit dot edu>
- Subject: Re: Pessimization
- From: Jim Wilson <wilson at cygnus dot com>
- Date: Tue, 19 May 1998 20:03:34 -0700
- cc: drepper at cygnus dot com (Ulrich Drepper), egcs at cygnus dot com
drepper:
> The real problem must have been deeper down in the code since Richard
> had similar problems with struct (!) on Alpha.
jfc:
The alias code assumes that a struct at a variable address does not
overlap a scalar at a fixed address.
You are talking about different things here. Ulrich Drepper was talking about
problems with the experimental aliasing code which has since been reverted.
That experimental code had at least 3 serious problems, and Ulrich refered
to two of them.
You are talking about problems with the old aliasing code that has been in
gcc for years.
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.
stdarg is not the only place where this can occur. There are a few
places in gcc that set/clear MEM_IN_STRUCT_P simply to avoid cases where the
aliasing code might get confused, and not because the object is an aggregate.
(The macro has `struct' in the name, but `aggregate' would be more accurate.)
This is nothing to worry about. These kinds of problems are trivial to fix.
2. Whether an address appears varying depends on optimizations. Code
like this may be incorrectly optimized:
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.
gcc2 does have the same bug. I first documented this bug on the gcc2 list
a long time ago. This has been a known bug ever since. It is very rare to
see occurences of it.
Hmm, just making a quick check of the my gcc2 mail archives, I see that
I gave a rather good description of the bug Jan 26, 1993, but it was obviously
a well known problem at the time, because I complained that I was tired of
explaining the problem again and again.
Anyways, the problem with disabling the aliasing code is that everyone will
find that their code suddenly runs slower. The alternative is that once every
two years or so someone finds a testcase that is miscompiled because of the
bug. I think the former is the better alternative.
Even better would be to fix the bug, but no one has volunteered to do this
yet. It will be quite a bit of work to fix the problem. Fixing it means
computing the `varying' info from the trees, and then progating it through
the RTL (like MEM_IN_STRUCT_P) instead of computing it on demand in alias.c.
This would require a very large patch, which would be hard to test.
Jim