[llvm-dev] Spill/Reload Instructions Due To Caller Saving Registers

[Armand Behroozi via llvm-dev]

Dear Nemanja,

Thank you for your thoughts!

I think you're correct in saying that this doesn't seem like something I
can recompute. I tried to re-compute the information by running some of the
liveness passes then re-analyzing at the preEmit2 stage, but
"LiveIntervals" error'ed out. I'm thinking this is b/c it wasn't meant to
be used so late in the codegen pipeline and may rely on SSA or something.

It's good to know what some of my alternatives are. I think I might go with
one of the hacks that you suggested.

Thanks again for your help. I appreciate you.

Regards,

Armand

On Wed, Mar 10, 2021 at 6:25 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
wrote:

> 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/5a98f55a/attachment.html>