llvm dev - Aug 2019 - Spills on second bank of registers

Hi Tim,

I wonder if you could help me with the following, even if just giving some
pointers about where to look. I previously posted a similar question in the
mailing list, but unfortunately I have not received a reply. This is the
subject:

I want to reduce the number of register spills to the stack that are created
around storeRegToStackSlot and loadRegFromStackSlot

In order to do so, I can use free registers from a second set of registers. The
idea is that these registers would be used as spills, instead of stack slots.
These registers may be free when they do not intervene in any instructions on a
given function.

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.

I am unsure about why this happens or how to correct/implement this, or where to
look. Any pointers would be appreciated.

Thanks,

Joan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190820/eaadf578/attachment.html>

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. 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.

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
VSFRC,
                                 (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.

  -Hal

>   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