llvm dev - Aug 2012 - [LLVMdev] Overriding TargetRegisterInfo::hasReservedSpillSlot

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.

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
-- 
Bill Schmidt, Ph.D.
IBM Advance Toolchain for PowerLinux
IBM Linux Technology Center
wschmidt at us.ibm.com
wschmidt at linux.vnet.ibm.com

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