[llvm-dev] IPRA, interprocedural register allocation, question

[Lawrence, Peter via llvm-dev]

Mehdi,
                 My bad,   I said  “3.8  trunk”   when I should have said “trunk”

--Peter.



From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Wednesday, July 13, 2016 4:48 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com>
Cc: vivek pandya <vivekvpandya at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; llvm-dev-request at lists.llvm.org; Hal Finkel <hfinkel at anl.gov>
Subject: Re: [llvm-dev] IPRA, interprocedural register allocation, question

You mentioned 3.8 earlier, and I doubt the code you are referring to here is in there, it is probably in trunk.

Now, anyway the patch wasn’t actually committed yet, it is as of r275347.


—
Mehdi



On Jul 13, 2016, at 4:28 PM, Lawrence, Peter <c_plawre at qca.qualcomm.com<mailto:c_plawre at qca.qualcomm.com>> wrote:

Mehdi,
                I’m seeing lots of “upgrading” logic,

                If (UseIPRA)
                                createPass(new DummyCGSCCPass);

                if (UseIPRA)
                                addPass(createRegUsageInfoPropPass());

                if (UseIPRA)
                                addPass(createRegUsageInfoCollector());

???


--Peter.


From: mehdi.amini at apple.com<mailto:mehdi.amini at apple.com> [mailto:mehdi.amini at apple.com]
Sent: Wednesday, July 13, 2016 4:26 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com<mailto:c_plawre at qca.qualcomm.com>>
Cc: vivek pandya <vivekvpandya at gmail.com<mailto:vivekvpandya at gmail.com>>; llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>; llvm-dev-request at lists.llvm.org<mailto:llvm-dev-request at lists.llvm.org>; Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>>
Subject: Re: [llvm-dev] IPRA, interprocedural register allocation, question


On Jul 13, 2016, at 4:24 PM, Lawrence, Peter <c_plawre at qca.qualcomm.com<mailto:c_plawre at qca.qualcomm.com>> wrote:

Mehdi,
               I am perusing the 3.8 trunk sources, and don’t find evidence where I
would expect it for LLVM “downgrading” a function’s calling convention.

IPRA is a project started ~ 2 months ago, there is nothing like that in 3.8 (neither downgrading, nor upgrading).

—
Mehdi






PrologEpilogEmitter() {         “CodeGen/”
     ...
     TFI->determineCalleeSaves() {        “Target/XYZ/”
           TargetFrameLowering::determineCalleeSaves() {   “CodeGen/”
                Return <<< some object derived from “*CallingConv.td” >>>;     “build/lib/Target/XYX/”
           }
           ...
           SavedRegs.set(Reg);  // to “add” a reg, EG for ‘hasFP’, ETC
           ...
     }
}

The SavedRegs set always starts out with a predefined calling-convention value
That comes typically from “*CallingConv.td” hence is not function-specific.

The only time SavedRegs.reset() is ever called (which is rarely to begin with)
are for target-specific, calling-conventions-specific reasons, never function-specific.

Perhaps I’m looking in the wrong place ?

But I think while we both agree that in principle LLVM could “downgrade” a function,
Given that it can provably see every call-site to it, it does not seem like this is actually
Happening, unless I’m missing something ???


(even if true I’m not claiming we’re missing an important case, I don’t have any
Logical arguments either way and don’t have any evidence either way.  I’m just
Trying to understand what LLVM actually does or does not do).


--Peter Lawrence.




2) it seems that LLVM currently limits itself to “upgrades” calling convention changes,
The reason being so that not all call sites are required to be changed,
therefore calls through function pointers can use the default calling convention
If for example there is insufficient analysis to know for sure what functions can be
called from that site.

Is my understanding #2 of IPRA in LLVM correct ?


I don’t believe this is correct, currently IPRA will limit itself to this for function that can be called from another module.
I will freely change the calling convention, including downgrades, when it knows that it can see all call sites (+ extra conditions, like no recursion being involved I think).

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