Re: Unreviewed RELOAD patch:http://gcc.gnu.org/ml/gcc-patches/2002-06/msg00649.html

[Alan Lehotsky <apl at alum dot mit dot edu>]

At 3:46 PM -0700 6/13/02, Geoff Keating wrote:
> Alan Lehotsky <apl@alum.mit.edu> writes:
>
> >  I originally submitted this on 5/31, since then, I've bootstrapped and
> >  regression tested it on SPARC Solaris 2.8, and built and tested a
> >  powerpc-apple-darwin5.5 compiler with the patch.  Things appear to
> >  work just fine in all cases.
> The patch is OK.
>
> Is the patch supposed to ensure that find_reloads_address always gets
> called with a non-NULL second parameter?
No.  There's ONE place where we have to call with a NULL, and that's 
in find_reloads() where we're looking at an operand that has a "p" 
constraint.  In this case, there's no MEM to provide is with 
something to hold the modified RTX if we allowed 
LEGITIMIZE_RELOAD_ADDRESS to do its transformations.



> If so, can you make another patch that removes all the tests for
> memloc being NULL in find_reloads_address, especially the one around
> the use of LEGITIMIZE_RELOAD_ADDRESS?
Nope.  Can't do it, unfortunately.  EVERY other call now guarantees 
that we pass the address of a MEM that will appear in the tree (so 
that the transformed address is the one that gets emitted), but the 
call
from find_reloads() would be hard to make work....

-- Al



--
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation