Redundant check for prologue_epilogue_contains in init_alias_analysis?

Redundant check for prologue_epilogue_contains in init_alias_analysis?

[Zdenek Dvorak]

Hello,

the following check in init_alias_analysis seems partially redundant,
partially wrong to me:

Index: alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.199
diff -c -3 -p -r1.199 alias.c
*** alias.c     12 Aug 2003 05:28:45 -0000      1.199
--- alias.c     22 Aug 2003 18:42:53 -0000
*************** init_alias_analysis (void)
*** 2785,2800 ****
            {
              rtx note, set;

- #if defined (HAVE_prologue) || defined (HAVE_epilogue)
-             /* The prologue/epilogue insns are not threaded onto the
-                insn chain until after reload has completed.  Thus,
-                there is no sense wasting time checking if INSN is in
-                the prologue/epilogue until after reload has completed.  */
-             if (reload_completed
-                 && prologue_epilogue_contains (insn))
-               continue;
- #endif
-
              /* If this insn has a noalias note, process it,  Otherwise,
                 scan for sets.  A simple set will have no side effects
                 which could change the base value of any other
register.  */
--- 2785,2790 ----


Calls to init_alias_analysis are of two types:

1) those before prologues and epilogues are added.  Then the condition
   is obviously useless.
2) those from scheduling.  Since scheduling reorders also prologue
   insns, it is wrong to ignore them here (in fact this caused a
   misscompilation with slightly modified hammer-branch gcc on ia64).

Am I correct with this analysis?

Zdenek

Re: Redundant check for prologue_epilogue_contains in init_alias_analysis?

[Jim Wilson]

Zdenek Dvorak wrote:
> the following check in init_alias_analysis seems partially redundant,
> partially wrong to me:

In many cases like this, the best answer is to look at the historical 
info.  We have 6 years of CVS and mailing list logs.  It isn't hard to 
find that the patch came from here
	http://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00048.html
and this message also explains why the patch is there.

For those that don't click through, the answer is that the FP won't be 
considered a constant base pointer if we process prologue/epilogue 
insns.  There are other ways to handle this problem without ignoring all 
prologue/epilogue instructions.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Redundant check for prologue_epilogue_contains in init_alias_analysis?

[Zdenek Dvorak]

Hello,

> Zdenek Dvorak wrote:
> >the following check in init_alias_analysis seems partially redundant,
> >partially wrong to me:
> 
> In many cases like this, the best answer is to look at the historical 
> info.  We have 6 years of CVS and mailing list logs.  It isn't hard to 
> find that the patch came from here
> 	http://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00048.html
> and this message also explains why the patch is there.
> 
> For those that don't click through, the answer is that the FP won't be 
> considered a constant base pointer if we process prologue/epilogue 
> insns.  There are other ways to handle this problem without ignoring all 
> prologue/epilogue instructions.

would then just forcing fp to be considered a constant base pointer
unconditionally be a solution?

Zdenek

Re: Redundant check for prologue_epilogue_contains in init_alias_analysis?

[Jim Wilson]

On Sun, 2003-09-07 at 02:59, Zdenek Dvorak wrote:
> would then just forcing fp to be considered a constant base pointer
> unconditionally be a solution?

That could work if there is no target that ever modifies FP during the
function, and if we can safely distinguish between real uses of the FP,
and cases where the FP was used by the register allocator.  This seems
likely to be true.

Another possible solution is to disregard instructions that modify FP if
they are prologue/epilogue instructions.  This seems safer, but is a bit
more code.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com