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

[Mehdi Amini via llvm-dev]

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> 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] 
> Sent: Wednesday, July 13, 2016 4:26 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
>  
>  
> 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/057be890/attachment-0001.html>