Patch fixing 3.3 bug PR 9745 and PR 10021

David Edelsohn dje@watson.ibm.com
Wed Jul 9 04:52:00 GMT 2003


	The performance problem can be understood without any
experiments.

	The current alias.c code mistakenly returns REG as a base value.
This behaves correctly and provides useful, unintended aliasing analysis
as long as REG is not the same as one of the magic ADDRESS bases.  For
targets without HARD_FRAME_POINTER_REGNUM, REG can be the same as
FRAME_POINTER_REGNUM, but the aliasing algorithm believes those two bases
cannot alias and returns incorrect aliasing analysis.  For PR 9745, this
causes the loop optimization pass to perform an unsafe move.

	For PR 9745, the compiler generated one reference to an array
directly offset from frame_pointer_rtx and another reference via a pseudo
set from frame_pointer_rtx.  The former had an ADDRESS base and the latter
a REG of FRAME_POINTER_REGNUM.  This divergence and incorrect aliasing
information occurred before loop optimization, so it was not created by
loop_regs_update.

	If the alias analysis algorithm is modified to return 0 instead of
REG, then the compiler must assume that anything may alias with that
pseudo.  As I described above, this does occur for objects allocated in
the stack frame.  With the proposed change, the compiler will not be able
to optimize memory references to objects allocated in the stack frame and
referenced in such a way that find_base_term currently calculates REG.  In
other words, the proposed change can disable alias-based optimization of
everything interacting with stack variables.  That has a disasterous
effect on performance.

Jim> Exposing the performance
Jim> regression will be inconvenient for some people, but it at least gives
Jim> those people incentive to fix the problem.

	Who are "those people"?  As you stated later in your message:

Jim> Looking at PR 9745, I see a comment from Janis Johnson pointing out that
Jim> the problem first appeared when David Miller eliminated SEQUENCE rtl. 

	According to the GCC Development Plan, which describes
responsibility for fixing bugs, David Miller is reponsible for fixing the
latent bug that his patch exposed.  David appears to be busy with other
responsibilities and nothing will increase his incentive to work on the
bug.

	"Those people" are all GCC developers, so the patch harms
performance and does not creat any direct responsibility for fixing either
the old bug or the performance regression.

	Based on your description, I believe that your latest patch to
scan the sequence before insertion should restore the loop optimizer
behavior prior to David Miller's elimination of SEQUENCE rtl.  That
probably will fix the failures described in the PRs.  I will test the
patch.

	I believe that restoring the original behavior is the best we can
do without a complete fix for the alias.c problems.

Thanks, David



More information about the Gcc mailing list