This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Problem with equivalent memory handling


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]