PATCH for alias set/stack temporary bug

Mark Mitchell mark@markmitchell.com
Sun Feb 28 18:15:00 GMT 1999


>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

    >> Wed Feb 10 10:00:29 1999 Mark Mitchell <mark@markmitchell.com>
    >> 
    >> * cse.c (dump_class): New function.  (invalidate_memory): Fix
    >> typo in comment.  * function.c (assign_stack_temp): Copy and
    >> clobber slots before reusing them.  * rtl.c (copy_rtx): Copy
    >> all the flags (in particular, MEM_SCALAR_P).

    Jeffrey> I don't think this will actually work reliably.

    Jeffrey> Consider that CLOBBER insns are deleted after reload has
    Jeffrey> completed.  Thus, nothing would prevent the second
    Jeffrey> scheduling pass from reordering the insns improperly.

I believe you.  However, I've thought about this carefully and I
really think that something like what I did is the right thing to do,
even if that means changing some other parts of the compiler to let
the CLOBBERs live.  Alternatively, we could introduce a
NOTE_MEM_CLOBBERED or some such.

I've got two arguments.  One is conceptual:

  When we reuse a stack temporary slot, it's conceptually similar 
  to calling `free' and then `malloc'.  In other words, we give back
  some memory.  Then we request some new memory.  It just happens to
  be the same as the memory we just gave away.  This can happen with
  free/malloc, too, and if the thing newly malloc'd is of a different
  type than the thing free'd then we get different alias sets for the
  corresponding memory.  But, we don't get burned because the compiler
  can see the calls to free/malloc (or, perhaps, a call to an
  arbitrary function, which it must assumes wreaks arbitrary havoc),
  and so considers all memory trashed across the call.  However, with
  stack temporaries there's no function call to give the compiler this
  clue; we need to introduce a similar hint.  CLOBBER seems like the
  right thing to say: Mr. Compiler, for reasons not otherwise obvious,
  this memory is being trashed, right now.  Maybe some kind of NOTE
  could convey the same information: for all INSNs after this one in
  the stream, even on different flow-of-control paths, should treat
  this memory as dead.  

The other argument is more practical:

  Any fiddling with the alias sets of the stack temporary itself is
  bound not to help.  Consider:
  
    int* f(int* ip); /* Implementation, somewhere else, is: 
                          { return ip; }  */
			  
    void g() {
      struct S {
        int i;
	int j;
      } s;
      int* ip = f(&s.i);

      *ip = 3;
    }

  Here there's just no way to know that the return value from `f'
  points into the stack.  The only thing to say is `ip points to an
  int', and we should be able to make use of that information.  It's
  true that `ip' cannot alias anything but an `int'.

So, we need to either give up on reusing stack slots (a horrible
performance hit, on some programs I've got) or figure out a way to
tell the compiler a stack slot is dead.

I'm happy to implement the solution.  Jeff, what do you think about
making the CLOBBERs live longer, perhaps if marked with a special
flag?

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com



More information about the Gcc-patches mailing list