This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Pessimization


	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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]