Vector registers assumed to be caller or callee-saved?

Andreas Klebinger klebinger.andreas at gmx.at
Sun Jun 30 21:01:28 UTC 2019


It is my understanding that we only communicate the calling convention
to be used via LLVM IR
  and LLVM handles generation of the save/restore instructions required
for the call.

So indeed neither the macro nor this function would be used there. But I
gathered that just by skimming
the LLVM code at times so maybe I got something wrong there.


Stefan Schulze Frielinghaus schrieb am 30.06.2019 um 20:36:
> But this only includes the NCG. What about the LLVM backend? For LLVM I
> only found in compiler/llvmGen/LlvmCodeGen/CodeGen.hs function
> definition getTrashRegs which makes use of function callerSaves which is
> defined in includes/CodeGen.Platform.hs:
>
> callerSaves :: GlobalReg -> Bool
> #if defined(CALLER_SAVES_Base)
> callerSaves BaseReg           = True
> #endif
> ...
> callerSaves _                 = False
>
> There only for general-purpose and floating-point registers function
> callerSaves may be defined to True. Thus, for XMMi, YMMi, and ZMMi
> arguments the function evaluates to False.
>
> Do I miss something for the LLVM backend? Maybe we just need to extend
> the definition of callerSaves in order to respect vector registers, too?
>
> Cheers,
> Stefan
>
>
> On Sun, Jun 30, 2019 at 07:16:15PM +0200, Andreas Klebinger wrote:
>> What you want is not the macro but this function:
>> https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs
>>
>>
>> whose results depend on the System ABI.
>>
>> Cheers,
>> Andreas
>>
>>
>>
>>
>>> Hi all,
>>>
>>> I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used
>>> by the STG machine: are those assumed to be caller or callee-saved? Only for
>>> the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in
>>> includes/stg/MachRegs.h.  However, I cannot find any other place where those
>>> macros are used.  AFAIK most C ABIs assume that vector registers are call
>>> clobbered. Is this also the case for GHC?
>>>
>>> Many thanks in advance,
>>> Stefan
>>>



More information about the ghc-devs mailing list