memrefs_conflict_p omission?

memrefs_conflict_p omission?

[Richard Henderson]

Something that came to mind a bit ago while fixing AND nonsense,
was that perhaps this was an omission?


r~


--- alias.c     1997/09/29 06:21:18     1.8
+++ alias.c     1997/10/06 07:08:16
@@ -594,7 +594,7 @@ memrefs_conflict_p (xsize, x, ysize, y,
     }

   if (y == frame_pointer_rtx || y == hard_frame_pointer_rtx
-      || y == stack_pointer_rtx)
+      || y == stack_pointer_rtx || y == arg_pointer_rtx)
     {
       rtx t = y;
       int tsize = ysize;
@@ -603,7 +603,7 @@ memrefs_conflict_p (xsize, x, ysize, y,
     }

   if (x == frame_pointer_rtx || x == hard_frame_pointer_rtx
-      || x == stack_pointer_rtx)
+      || x == stack_pointer_rtx || x == arg_pointer_rtx)
     {
       rtx y1;

Re: memrefs_conflict_p omission?

[John Carr]

> Something that came to mind a bit ago while fixing AND nonsense,
> was that perhaps this was an omission?

That code came from sched.c and I don't think I changed it (at least
not in the final version -- I remember working on that code but I
later decided the base-address aliasing was better done elsewhere).  I
suspect that the block controlled by the condition you changed in the
second part of your patch is no longer needed with the new base
address alias code.

The change is at least half correct: the argument pointer itself can
never alias a global symbol.  One thing to check is whether in any of
the targets the argument pointer can be variable.  If so your change
might not be safe.  The scheduler would not realize that the two
memory references in

	[arg pointer + 4] = x
	arg pointer += 4
	[arg pointer] = y

are to the same address.

Re: memrefs_conflict_p omission?

[Jeffrey A Law]

  In message < 199710061344.JAA24923@no-knife.MIT.EDU >you write:
  > 
  > > Something that came to mind a bit ago while fixing AND nonsense,
  > > was that perhaps this was an omission?
  > 
  > That code came from sched.c and I don't think I changed it (at least
  > not in the final version -- I remember working on that code but I
  > later decided the base-address aliasing was better done elsewhere).
It looks like it was just lifed from sched.c unchanged.

  I
  > suspect that the block controlled by the condition you changed in the
  > second part of your patch is no longer needed with the new base
  > address alias code.
  > 
  > The change is at least half correct: the argument pointer itself can
  > never alias a global symbol.  One thing to check is whether in any of
  > the targets the argument pointer can be variable.  If so your change
  > might not be safe.  The scheduler would not realize that the two
  > memory references in
  > 
  > 	[arg pointer + 4] = x
  > 	arg pointer += 4
  > 	[arg pointer] = y
  > 
  > are to the same address.
Well, where do we want to go?  I'm going to lean on you for most alias
problems :-)

Jeff

Re: memrefs_conflict_p omission?

[Richard Henderson]

> One thing to check is whether in any of
> the targets the argument pointer can be variable.  If so your change
> might not be safe.  The scheduler would not realize that the two
> memory references in
> 
> 	[arg pointer + 4] = x
> 	arg pointer += 4
> 	[arg pointer] = y

Nope.  It is always either eliminated to FP/SP, or is FP.  With the
exception of vax and we32k.  And vax doesn't change its AP, and I am
assuming we32k works the same way.  It doesn't appear to move...


r~

Re: memrefs_conflict_p omission?

[meissner]

| Nope.  It is always either eliminated to FP/SP, or is FP.  With the
| exception of vax and we32k.  And vax doesn't change its AP, and I am
| assuming we32k works the same way.  It doesn't appear to move...

It couldn't very well point to the arguments on the stack if it moved.