llvm dev - Oct 2011 - [LLVMdev] Request for merge: GHC/ARM calling convention.

Hi Duncan, Karel,

On 14 October 2011 08:22, Duncan Sands <baldrick at free.fr>
wrote:
> Hi Karel,
>
>>>> > const unsigned*
>>>> > ARMBaseRegisterInfo::getCalleeSavedRegs(const
MachineFunction *MF)
>>>> const {
>>>> > + bool ghcCall = false;
>>>> > +
>>>> > + if (MF) {
>>>> > + const Function *F = MF->getFunction();
>>>> > + ghcCall = (F ? F->getCallingConv() ==
CallingConv::GHC : false);
>>>> > + }
>>>>
>>>> > This bit looks dubious. Why do you need to do it?
>>>>
>>>> What exactly? We need to test if this is GHC calling convention
or not
>>>> and if
>>>> its, then return different set of callee saved regs. What
exactly
>>>> don't you like
>>>> on this piece?
>>>
>>> I don't see anyone else rummaging around inside the original
function
>>> for the
>>> calling convention, so why do you need to?
So I wrote the first version of the GHC calling convention for X86,
and also basically the code in question above as its copied from the
X86 implementation. I had a look over the code and will try to explain
what I believe is going on but I may be mistaken as this is code I
haven't looked at for over a year.

The code above is needed as the GHC calling convention redefines what
registers are considered callee save. No one else rummages in to the
original function as all the other calling conventions use the same
set of callee and caller save registers, so GHC is the only one that
needs to differentiate.
>> Based on knowledge of calling convention we return different set of
callee saved
>> registers. For example on ARM and when GHC CC is used, we return empty
set.
>
> yeah, but here MF is (presumably) the callee.  The callee shouldn't be
relevant
> to how arguments are marshalled at the call-site.  Especially as there
might not
> even be a callee function (case of an indirect call).  Since calls
themselves
> are annotated with the calling convention to use, I guess the calling
convention
> should be grabbed from the call instruction itself somehow.
This isn't about the call-site. My understanding is that when the
prologue / epilogue code for a function (MF) is being generated this
'getCalleeSavedRegs' function is consulted to determine what to push
and pop. So yes MF is callee but I don't think this function is
affecting the call site marshaling. One thing to note is that the GHC
calling convention is intended to be used as in a tail call
optimization fashion (the code GHC generates with LLVM never returns,
its CPS code) so maybe this is complicating matters a little. We don't
really have 'call sites' using the GHC call convention since they're
all tail calls that are jumps and will never return.

Cheers,
David

Hi David,
> The code above is needed as the GHC calling convention redefines what
> registers are considered callee save. No one else rummages in to the
> original function as all the other calling conventions use the same
> set of callee and caller save registers, so GHC is the only one that
> needs to differentiate.
shouldn't the caller also know what registers are callee saved so that it
can avoid saving the contents of those registers to the stack?
>>> Based on knowledge of calling convention we return different set of
callee saved
>>> registers. For example on ARM and when GHC CC is used, we return
empty set.
>>
>> yeah, but here MF is (presumably) the callee.  The callee shouldn't
be relevant
>> to how arguments are marshalled at the call-site.  Especially as there
might not
>> even be a callee function (case of an indirect call).  Since calls
themselves
>> are annotated with the calling convention to use, I guess the calling
convention
>> should be grabbed from the call instruction itself somehow.
>
> This isn't about the call-site.
I see, thanks for explaining.  But then can the MachineFunction really be null?

Ciao, Duncan.

On 15 October 2011 00:31, Duncan Sands <baldrick at free.fr>
wrote:
> Hi David,
>
>> The code above is needed as the GHC calling convention redefines what
>> registers are considered callee save. No one else rummages in to the
>> original function as all the other calling conventions use the same
>> set of callee and caller save registers, so GHC is the only one that
>> needs to differentiate.
>
> shouldn't the caller also know what registers are callee saved so that
it
> can avoid saving the contents of those registers to the stack?
I assume so, I'm not an expert on LLVM or this area at all really.
What's the follow on logic / question here?
>
>>>> Based on knowledge of calling convention we return different
set of
>>>> callee saved
>>>> registers. For example on ARM and when GHC CC is used, we
return empty
>>>> set.
>>>
>>> yeah, but here MF is (presumably) the callee.  The callee
shouldn't be
>>> relevant
>>> to how arguments are marshalled at the call-site.  Especially as
there
>>> might not
>>> even be a callee function (case of an indirect call).  Since calls
>>> themselves
>>> are annotated with the calling convention to use, I guess the
calling
>>> convention
>>> should be grabbed from the call instruction itself somehow.
>>
>> This isn't about the call-site.
>
> I see, thanks for explaining.  But then can the MachineFunction really be
> null?
Yes. For the X86 equiv of this code (X86RegisterInfo.cpp) the 'if
(MF)' lines already existed before my patch. So I assume the existing
code was correct. A quick grep for calls to 'getCalleeSavedRegs' also
shows some calls in some optimisation passes that don't pass in an
argument and the default argument is null.

Hope this all helps. Is there someone who 'owns' this section of the
code that we can rope into the discussion though as I'm not that
qualified.

Cheers,
David