[LLVMdev] Request for merge: GHC/ARM calling convention.

David Terei davidterei at gmail.com
Tue Oct 18 10:59:33 PDT 2011


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
>




More information about the llvm-dev mailing list