[LLVMdev] Overriding TargetRegisterInfo::hasReservedSpillSlot

[William J. Schmidt]

On Fri, 2012-08-31 at 11:41 -0500, William J. Schmidt wrote:
> To fix some problems with how condition registers are saved/restored for
> PowerPC, I need to override TargetRegisterInfo::hasReservedSpillSlot()
> in PPCRegisterInfo.  I've had some difficulties because of the constness
> of the function, and I'm wondering what the best way to handle this
> would be.
> 
> Essentially I need to add a field to PPCRegisterInfo, and modify that
> field in hasReservedSpillSlot.  (I need to reserve the spill slot only
> if condition registers are to be spilled, and reserve it only once even
> if more than one is to be spilled; so I need state that persists across
> multiple calls to this function.)  Because hasReservedSpillSlot is
> annotated as const, I can't do this directly.
> 
> There appear to be several options:
>  * Add the field as an int& instead of an int.  This requires it to be
> allocated in the constructor's initializer, which is rather ugly:
> NewField(*(new int)).
>  * Remove the constness from the virtual function in the superclass and
> other subclasses (currently only X86).  This is bad if it's const by
> design, but OK if it was just const by habit.  It would probably be good
> to change the name of the function to indicate potential modification in
> that case.
>  * Add another target hook that only PowerPC will use initially in order
> to set up the reserved spill slot.  This basically would move almost all
> the PowerPC logic out of hasReservedSpillSlot() into the new hook in
> order to circumvent the const issue.  This works but bothers me a little
> since it's a lot of hoop-jumping just to bypass const.

Well, it appears that only the first option is open to me.  For reasons
I don't fully understand (still blowing the dust off my C++), I can't
have a non-const virtual function in the TargetRegisterInfo class.  As
soon as I introduce one, I get a conversion error indicating that my
subclass has lost necessary constness:

/home/wschmidt/llvm/llvm-test4/lib/CodeGen/PrologEpilogInserter.cpp: In member function ‘void llvm::PEI::calculateCalleeSavedRegisters(llvm::MachineFunction&)’:
/home/wschmidt/llvm/llvm-test4/lib/CodeGen/PrologEpilogInserter.cpp:251:53: error: no matching function for call to ‘llvm::TargetRegisterInfo::createOptionalReservedSpillSlot(llvm::MachineFunction&, unsigned int&) const’
/home/wschmidt/llvm/llvm-test4/lib/CodeGen/PrologEpilogInserter.cpp:251:53: note: candidate is:
In file included from /home/wschmidt/llvm/llvm-test4/lib/CodeGen/PrologEpilogInserter.h:30:0,
                 from /home/wschmidt/llvm/llvm-test4/lib/CodeGen/PrologEpilogInserter.cpp:23:
/home/wschmidt/llvm/llvm-test4/include/llvm/Target/TargetRegisterInfo.h:659:16: note: virtual void llvm::TargetRegisterInfo::createOptionalReservedSpillSlot(llvm::MachineFunction&, unsigned int) <near match>
/home/wschmidt/llvm/llvm-test4/include/llvm/Target/TargetRegisterInfo.h:659:16: note:   no known conversion for implicit ‘this’ parameter from ‘const llvm::TargetRegisterInfo*’ to ‘llvm::TargetRegisterInfo*’

So in the absence of any other suggestions, I suppose I will go with
using a reference field.

Bill

> 
> Which of the above, or any other possibilities, would you consider to be
> the best approach?
> 
> (While I'm on the topic of this function, it's a little bothersome that
> the MachineFunction &MF parameter is marked const also.  It makes it
> impossible to call MF.getFrameInfo() without casting the constness away.
> In such cases, is it best to cast away const, or remove the qualifier
> from the parameter?)
> 
> Thanks for any help!
> Bill