[llvm-dev] Spills on second bank of registers

Finkel, Hal J. via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 21 06:05:55 PDT 2019

On 8/21/19 4:02 AM, Tim Northover via llvm-dev wrote:
> Hi Joan,
> On Tue, 20 Aug 2019 at 08:29, Joan Lluch <joan.lluch at icloud.com> wrote:
>> I assumed that, by default, LLVM would figure out that there are free registers (albeit from a different register class) and would use them as temporaries instead of creating stack spills of the regular register set. However this is not the case. The stack spills are created anyway despite being registers unused on the second register bank.
> As far as I know LLVM doesn't have this ability.

I don't think that's quite right, however, you need to have a register 
class containing both relevant classes and you need to implement 
*RegisterInfo::getLargestLegalSuperClass. An example might be to look at 
PowerPC's SPILLTOVSRRC register class:

// Allow spilling GPR's into caller-saved VSR's.
def SPILLTOVSRRC : RegisterClass<"PPC", [i64, f64], 64, (add G8RC, (sub 
                                 (sequence "VF%u", 31, 20),
                                 (sequence "F%u", 31, 14)))>;

which is referenced in PPCRegisterInfo::getLargestLegalSuperClass, and 
in general, I think that if you grep for SPILLTOVSRR in 
lib/Target/PowerPC you'll see everything.


>   The ARM CPUs that can
> only run Thumb1 code (e.g. Cortex-M0) could theoretically benefit from
> such a scheme too, but no-one has so far thought it worth
> implementing.
> I'm afraid I've not really looked into the details of how LLVM
> allocates stack slots, but that would be the obvious place to add the
> ability generically. It would have to be a new kind of slot that's
> (probably) volatile across function calls, unlike normal ones.
> Alternatively, you could always try a MachineFunctionPass to peephole it.
> Cheers.
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

More information about the llvm-dev mailing list