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

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

Hi Duncan,

Any word on this making 3.0?

Cheers,
David

On 16 October 2011 23:03, David Terei <davidterei at gmail.com>
wrote:
> 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
>

Hi David,
> Any word on this making 3.0?
3.0 already branched, and since this is not a regression, this will
most probably go into 3.1.

Maybe Bill (CC'ed) being the release manager has other opinion on this.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University