llvm dev - Mar 2021 - Spill/Reload Instructions Due To Caller Saving Registers

Doesn't TargetInstrInfo::isStoreToStackSlot() tell you if the instruction
is a spill? Or are you looking to identify spill/reload instructions after
frame indices are eliminated?

On Mon, Mar 8, 2021 at 9:32 AM Armand Behroozi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> I'm trying to identify which spill/reload instructions save/reload
virtual
> registers that are live across function calls. In other words, if a virtual
> reg is spilled before a call, reloaded after, and live during the call, I
> want to remember it.
>
> I've figured out how to determine if a virtual register has its live
range
> across a call instruction: I use the
"checkRegMaskInterference(VirtReg)"
> method. Then, if storeRegToStackSlot or loadRegFromStackSlot is called
> while there's regmask interference, I know that a spill/reload
instruction
> was created as well and mark its MCInstrDesc as fitting my criteria.
>
> The issue I'm facing is that I don't know how to propagate this
> information from the RegAlloc stage to the end of the codegen pipeline as
> instructions are frequently created and destroyed, so the instructions and
> their MCInstrDesc don't survive until the end of
"addPreEmitPass2."
>
> Any thoughts on how to tackle this challenge would be greatly appreciated.
>
> Thank you.
>
> Regards,
>
> Armand Behroozi
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210309/89ea8063/attachment.html>

Hello,

Thank you for your response.

TargetInstrInfo::isStoreToStackSlot() does tell you if an instruction is a
spill; but I'm only interested in a subset of spills. I'm trying to find
a
way to filter the other ones out.
I believe frame indices have been eliminated b/c I have been using
"isStoreToStackSlotPostFE" and "hasStoreToStackSlot" to
determine if an
instruction is a spill. The pass I built is running at the end of
preEmitPass2.

I want to test the efficacy of a technique for reducing the number of
register spills/reloads, but it can only address a subset of them (cannot
handle the case where virtual registers are live across function calls).
I'm trying to quantify how big this subset is and if it's worth doing
the
project.

I'm able to identify the subset during the register allocation phase, but
as spills/reloads are moved and hoisted, and new spill/reload instructions
are created while others are deleted, I lose track of how many of these
spills/reloads make it to the final code. This is important, b/c I want to
look at the dynamic spill/reload count, not just the static count.

Thank you.

Regards,

Armand

On Tue, Mar 9, 2021 at 10:49 AM Nemanja Ivanovic <nemanja.i.ibm at
gmail.com>
wrote:
> Doesn't TargetInstrInfo::isStoreToStackSlot() tell you if the
instruction
> is a spill? Or are you looking to identify spill/reload instructions after
> frame indices are eliminated?
>
> On Mon, Mar 8, 2021 at 9:32 AM Armand Behroozi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello,
>>
>> I'm trying to identify which spill/reload instructions save/reload
>> virtual registers that are live across function calls. In other words,
if a
>> virtual reg is spilled before a call, reloaded after, and live during
the
>> call, I want to remember it.
>>
>> I've figured out how to determine if a virtual register has its
live
>> range across a call instruction: I use the
>> "checkRegMaskInterference(VirtReg)" method. Then, if
storeRegToStackSlot or
>> loadRegFromStackSlot is called while there's regmask interference,
I know
>> that a spill/reload instruction was created as well and mark its
>> MCInstrDesc as fitting my criteria.
>>
>> The issue I'm facing is that I don't know how to propagate this
>> information from the RegAlloc stage to the end of the codegen pipeline
as
>> instructions are frequently created and destroyed, so the instructions
and
>> their MCInstrDesc don't survive until the end of
"addPreEmitPass2."
>>
>> Any thoughts on how to tackle this challenge would be greatly
appreciated.
>>
>> Thank you.
>>
>> Regards,
>>
>> Armand Behroozi
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210309/6830f5f6/attachment-0001.html>