Your Jan 8th, 2001 rtlanal.c:note_stores change

David S. Miller davem@redhat.com
Mon Apr 15 06:45:00 GMT 2002


   From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
   Date: Mon, 15 Apr 02 09:23:32 EDT

   The problem is that it's certainly also not the case that *each* of the
   registers in question is being set to the result of the CALL.  I don't
   remember the exact bug, but that was basically what was going wrong.
   
   I agree that CLOBBER isn't precisely correct *either*.
   
I think that saying each is SET is much better than saying each is
CLOBBERed.

I don't understand how a CLOBBER is better than a SET in any way for
this case.  Again, the details of why you decided to use CLOBBER are
important.  Please try to remember.  Was someone looking inside of the
second argument to the callback function and getting confused at
seeing the PARALLEL?  That callback should have been fixed instead, if
so.

In fact, for the purposes of the note_stores callback, SET is about as
precise as you can get.  I think you're too worked up about the fact
that this is a PARALLEL and the usual semantics of PARALLELs.  This
isn't like a normal PARALLEL, it's just a group of hard regs being
SET.  And the note_stores callback should not care past seeing it is
a SET.

If you can't remember the exact bug, can you at least pull out the
sparc64 test case that led you to make all of these changes?  In your
Jan. 18th, 2001 posting to gcc-patches you mention that this was
discussed "all over the lists", but I am having trouble finding these
discussions about your "sparc64 bug" and how to handle PARALLEL
SET_DEST.  I walked from Jan 18th 2001 all the way back to mid-2000 on
the lists and I can't find anything relevant.

This is why it's really important to specifically reference (via URLs
or filenames in the source tree) a specific test-case or mailing list
thread discussing the problem when posting a patch to gcc-patches :-)
In this way when your change causes problems for someone else, that
person can accurately understand why you made your change and propose
a fix for his problem which does not end up breaking your original
case again.



More information about the Gcc-bugs mailing list