Re: slot combination and alias analysis

[mike stump <mrs at windriver dot com>]

> Date: Fri, 5 Oct 01 21:20:42 EDT
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: rth@redhat.com
> Cc: gcc@gcc.gnu.org

> The whole issue of reusing temp slots is much trickier than it seems
> and I'm still not sure we have it right.

I think I can spot a bug (in one of your changes):

int
objects_must_conflict_p (t1, t2)
     tree t1, t2;
{
  /* If neither has a type specified, we don't know if they'll conflict
     because we may be using them to store objects of various types, for
     example the argument and local variables areas of inlined functions.  */
  if (t1 == 0 && t2 == 0)
    return 0;

The previous version did the equivalent of:

int
objects_must_conflict_p (t1, t2)
     tree t1, t2;
{
  /* If neither has a type specified, we don't know if they'll conflict
     because we may be using them to store objects of various types, for
     example the argument and local variables areas of inlined functions.  */
  if (t1 == 0 || t2 == 0)
    return 0;

I think.  It was previously:

        || (alias_set && p->alias_set == alias_set))

which meant if either was zero, it would be false.  The reasoning is
that an unknown type (the abuse of alias set zero in the old code),
can be remapped to any alias set beyond our ability to know about it
(say, by function inlining), and that the slots won't necessarily
conflict.