Problem with equivalent memory handling

Jeff Law law@redhat.com
Tue Oct 19 19:25:00 GMT 2010


  Looking for advice here -- while I haven't seen this bug trigger in 
the mainline, it triggers  with the range splitting code I've been 
working on.

Reload has the ability to replace a pseudo with its equivalent memory 
location.  This is fine and good.

Imagine:

   1. We have a pseudo (call is pseudo A) with a read-only memory 
equivalent.  Pseudo A does not get a hard reg

   2. Pseudo A crosses a call (because the memory is readonly, we will 
not invalidate the equivalency)

   3. The equivalent memory address references another pseudo (call it 
pseudo B)

   4. Pseudo B does not cross calls and is assigned a call-clobbered 
hard reg.

   5. reload replaces pseudo A with its equivalent memory form and in 
doing so lengthens the lifetime of pseudo B and causes pseudo B to be 
live across a call.

Obviously this is bad.  The question is where/how do we want to catch it.

The easy solution is to go ahead and invalidate the equivalency once we 
notice that pseudo A crosses a call, even though the memory equivalent 
is readonly.  Seems a little harsh, but it's a one line change.



Other approaches?

Jeff






More information about the Gcc mailing list