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
[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
[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>