From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@cygnus.com>
To: John Carr <jfc@mit.edu>
Cc: Richard Henderson <rth@cygnus.com>, egcs@cygnus.com
Subject: Re: memrefs_conflict_p omission? 
Date: Tue, 07 Oct 1997 23:14:00 -0000
Message-id: <6275.876264736@hurl.cygnus.com>
References: <199710061344.JAA24923@no-knife.MIT.EDU>
X-SW-Source: 1997-10/msg00298.html

  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