thr3ads.net - llvm dev - [llvm-dev] IPRA, interprocedural register allocation, question [Jul 2016]

If this information is useful, please help other people find it:
Share via:

Lawrence, Peter via llvm-dev

2016-Jul-13 23:24 UTC

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

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.

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

Mehdi Amini via llvm-dev

2016-Jul-13 23:25 UTC

head link

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

> On Jul 13, 2016, at 4:24 PM, Lawrence, Peter <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/ea8cae3b/attachment.html>

Lawrence, Peter via llvm-dev

2016-Jul-13 23:28 UTC

head link

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

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/021774cc/attachment.html>

Reasonably Related Threads

Search for more seemingly similar threads

llvm dev - Jul 2016 - IPRA, interprocedural register allocation, question

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

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

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

Reasonably Related Threads