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

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>

I think this is an example of something that is generally tricky to do. You
are essentially interested in preserving information about instructions
across transformation passes. This is generally achieved by analysis passes
that transformations can either clobber or preserve. However, it seems like
this isn't something you can re-compute.
If this is just a temporary hack that you want to implement to give you
this information, I suppose you can either add a flag to the MachineInstr
to mark it as a specific type of spill/reload you are interested in. Or
perhaps add a SmallPtrSet to MachineFunctionInfo that would track the
instructions you're interested in.

On Tue, Mar 9, 2021 at 12:36 PM Armand Behroozi <armandb at umich.edu>
wrote:
> 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/20210310/40535d26/attachment.html>