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] |
Jeff Law<law@redhat.com> writes:That's the problem -- we don't know until reload has completed whether or not the pseudo with the equivalent memory location will get a hard register or not.
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.If you can spot this before reload, then you can load the memory address into a new pseudo C, and let the register allocator decide whether to save C on the stack or rematerialize it as needed.
Right.Otherwise, if you don't invalidate the equivalency, you are effectively extending the lifetime of pseudo B so that it lives across a call.
Not today, which is the problem. Pseudo B continues to live in the call-clobbered register which can have its value clobbered by the call if we replace A with its memory equivalent. ie, we generate incorrect code.If there is any register pressure, B is going to go onto the stack or is going to force something else onto the stack.
Agreed. I'll prepare a patch.At that point, you would have been better off just putting the memory address on the stack instead of pseudo B. So I think that invalidating the equivalency across a function call is probably the right thing to do.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |