Displaying 16 results from an estimated 16 matches for "profilesummari".
Did you mean:
profilesummary
2016 Apr 18
2
Move InlineCost.cpp out of Analysis?
On 04/18/2016 04:05 PM, Easwaran Raman via llvm-dev wrote:
>
>
> On Mon, Apr 18, 2016 at 3:25 PM, Chandler Carruth <chandlerc at gmail.com
> <mailto:chandlerc at gmail.com>> wrote:
>
> On Mon, Apr 18, 2016 at 3:20 PM Easwaran Raman <eraman at google.com
> <mailto:eraman at google.com>> wrote:
>
> On Mon, Apr 18, 2016 at 3:00 PM,
2016 Apr 18
2
Move InlineCost.cpp out of Analysis?
Hi,
After r256521 - which removes InlineCostAnalysis class - I think there
is no strong reason for InlineCost.cpp to be part of the Analysis library.
Is it fine to make it part of TransformUtils?
I submitted r266477 (which has now been reverted) that made Analysis depend
on ProfileData in order to obtain ProfileSummary for the module, but there
is an existing dependency of ProfileData on
2016 Apr 18
5
Move InlineCost.cpp out of Analysis?
> On Apr 18, 2016, at 2:07 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> ----- Original Message -----
>> From: "Easwaran Raman" <eraman at google.com>
>> To: "via llvm-dev" <llvm-dev at lists.llvm.org>
>> Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Hal Finkel" <hfinkel at
2016 Apr 18
4
Move InlineCost.cpp out of Analysis?
On Mon, Apr 18, 2016 at 3:20 PM Easwaran Raman <eraman at google.com> wrote:
> On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov> wrote:
>>
>>>
>>>
>>> ------------------------------
>>>
>>>
2016 Apr 18
5
Move InlineCost.cpp out of Analysis?
On Mon, Apr 18, 2016 at 2:18 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> The difference between Analysis and Transforms is *not* about passes, but
> about what the code *does*.
>
> Code for mutating the IR should be in Transforms, and code that analyzes
> the IR without mutating it should be in Analysis. This is why, for example,
> InstructionSimplify is in
2016 Apr 18
2
Move InlineCost.cpp out of Analysis?
On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> On Apr 18, 2016, at 2:28 PM, Xinliang David Li <davidxl at google.com> wrote:
>
>
>
> On Mon, Apr 18, 2016 at 2:18 PM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>> The difference between Analysis and Transforms is *not* about passes, but
>> about what
2017 Aug 15
8
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
Hello,
My team and I are looking to do some enhancements in the partial inliner
in opt. Would appreciate any feedback that folks might have.
# Partial Inlining in LLVM opt
## Summary
### Background
Currently, the partial inliner searches the first few blocks of the callee
and looks for a branch to the return block (ie. early return). If found,
it attempts to outline the rest of the
2017 Aug 15
3
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
Hi Jessica,
Thanks for the feedback.
I believe the existing partial inliner pass does use some common utilities
like the code extractor to do outlining. Is that what you're referring to?
I don't recall seeing any other passes that has outlining other than the
machine outliner, but I may have missed something.
I briefly looked at River's RFC and it seems he's mainly utilizing
2017 Aug 24
1
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
Hi David,
So I've began doing some implementation on the outlining portion of the
code. Currently, I got the partial inliner to outline cold regions (single
entry, single exit) of the code, based solely on the existence of
ProfileSummaryInfo (ie. profiling data). However, I have some concerns on
how this will co-exist with the existing code that peels early returns.
The control flow looks
2017 Aug 15
2
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
On Tue, Aug 15, 2017 at 4:14 PM, River Riddle via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hey Graham,
> I worked on pretty much this exact thing last year. I did something
> similar to what you described, I traversed the CFG and built potentially
> profitable regions from any given valid start node. At that point there
> were several road blocks that prevented it
2017 Aug 24
3
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
Hi David,
The only reason I can see to use the 'pattern matching' part as a fall-back
is in case we cannot inline the (what I'm assuming would be) a much bigger
hot-path-only cloned function for whatever reason. What I'm assuming here
is that after cold-region outlining, we may still have a large portion of
the original function body to attempt to inline, whereas the pattern
2017 Aug 29
3
[RFC] Enhance Partial Inliner by using a general outlining scheme for cold blocks
I second the fact that a way to outline specific function regions
independently of the partial inliner sound very useful. I am not sure
however if we would want a mode within the partialInliner or something
completely independent.
As a general question, does anybody has a clear idea of what are the
constraints on the region CodeExtractor is currently able to handle ?
Going through the code, it
2016 Apr 18
6
Move InlineCost.cpp out of Analysis?
On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov> wrote:
>
>
> ------------------------------
>
> *From: *"Xinliang David Li" <davidxl at google.com>
>
> On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com>
> wrote:
>>
>> In the current case at stake: the issue is that we can't make the
>>
2016 Apr 18
2
Move InlineCost.cpp out of Analysis?
----- Original Message -----
> From: "Chandler Carruth" <chandlerc at gmail.com>
> To: "Xinliang David Li" <davidxl at google.com>
> Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "Hal Finkel"
> <hfinkel at anl.gov>, "via llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, April 18, 2016 4:31:05 PM
2019 Sep 12
6
PGO is ineffective for Rust - but why?
Hi everyone,
As part of my work for Mozilla's Low Level Tools team I've
implemented PGO in the Rust compiler. The feature is
available since Rust 1.37 [1]. However, so far we have not
seen any actual performance gains from enabling PGO for
Rust code. Performance even seems to drop 1-3% with PGO
enabled. I wonder why that is and I'm hoping that someone
here might have experience
2016 Sep 02
2
[ThinLTO] Importing based on PGO data
The profile summary is saved in the global metadata ASAIK. If we want to
calculate if something is hot/cold while choosing functions for importing,
we would either need to read whole Module (which we clearly don't want to
do)
or duplicate this information in the summary, so we could get it without
reading Module.
2016-09-02 15:49 GMT-07:00 Mehdi Amini <mehdi.amini at apple.com>:
>