search for: profilesummary

...through an API that can do intelligent things like > synthesizing it from the "cold" attribute or whatever when > missing. > > > Invariants b) and c) above are still true, but a) is not since > InlineCost directly calls ProfileSummary instead of through an > analysis pass. > > > Not quite -- ProfileSummary seems to only exist in the profile > *reading* code, so it isn't *just* an annotation on the IR. > > Sorry, I'm lost here. There is an IR annotation (module flag) called > Profi...

...r 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 Analysis (through Object and BitCode). Moving InlineCost.cpp under Transforms/Utils will fix this issue. There are other ways to fix this (make Inliner.cpp get the ProfileSummary and pass it to InlineCost, for example), but I thi...

...> Given that InlineCost is not really an analysis any longer, I think this is fine. Isn't it? It is not a pass, but I see it as an analysis utils. > >> >> 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 >> Analysis (through Object and BitCode). The real issue is that BitCode depends on Analysis I think. I'm not sure about ProfileData that depends on Bitcode, do you know why? -- Mehdi >> Moving Inlin...

...brokers >> access to these annotations through an API that can do intelligent things >> like synthesizing it from the "cold" attribute or whatever when missing. >> >> > Invariants b) and c) above are still true, but a) is not since InlineCost > directly calls ProfileSummary instead of through an analysis pass. > Not quite -- ProfileSummary seems to only exist in the profile *reading* code, so it isn't *just* an annotation on the IR. I think the problem here is that we have failed to build a proper separate abstraction around the interprocedural profile data t...

...hink >> this is fine. >> >> Isn't it? It is not a pass, but I see it as an analysis utils. >> >> > >> >> >> >> 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 >> >> Analysis (through Object and BitCode). >> >> The real issue is that BitCode depends on Analysis I think. >> I'm not sure about ProfileData that depends on Bitcode, do you...

...>>> >>> Isn't it? It is not a pass, but I see it as an analysis utils. >>> >>> > >>> >> >>> >> 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 >>> >> Analysis (through Object and BitCode). >>> >>> The real issue is that BitCode depends on Analysis I think. >>> I'm not sure about ProfileData that depends...

...ation as part of the function cloning container. In order to outline multiple regions of the function, we will need to change these containers to keep track of a list of regions to outline. We will also need to update the cost analysis to take into account multiple outlined functions. When a ProfileSummary is available, then we should skip the code that looks for early returns and go into new code that looks for cold regions to outline. When ProfileSummary is not available, then we can fall back to the existing code and look for early returns only. ### Tuning - The outlining heuristics will n...

...ction cloning container. In order to outline multiple regions of the function, we will need to change these containers to keep track of a list of regions to outline. We will also need to update the cost analysis to take into account multiple outlined functions. When a ProfileSummary is available, then we should skip the code that looks for early returns and go into new code that looks for cold regions to outline. When ProfileSummary is not available, then we can fall back to the existing code and look for early returns only. ### Tuning - The out...

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 something like this: // New Code: find cold regions to outline if (!computeOutliningInfoForColdRegions()) { // If we can't find any cold...

...utline multiple regions of the function, we will need to change >> these containers to keep track of a list of regions to outline. We will >> also need to update the cost analysis to take into account multiple >> outlined functions. >> >> When a ProfileSummary is available, then we should skip the code >> that looks for early returns and go into new code that looks for cold >> regions to outline. When ProfileSummary is not available, then we can fall >> back to the existing code and look for early returns only. >&gt...

...017 at 10:40 AM, Graham Yiu <gyiu at ca.ibm.com> wrote: 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 something like this: // New Code: find cold regions to outline if (!computeOutliningInfoForColdRegions()) { // If we can't find a...

...gt; >> 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 something like this: >> >> // New Code: find cold regions to outline >> if (!computeOutl...

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

...> > > > > >> > > > > > > > > > > >> 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 > > > > > > > > > > >> Analysis (through Object and BitCode). > &gt...

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

...2:58 PM, Piotr Padlewski >> <piotr.padlewski at gmail.com> wrote: >> > Hi, >> > I am working right now on importing based on PGO/FDO data. There is one >> > issue that I found - when we calculate the list of imports, we can't >> get the >> > ProfileSummaryInfo, which is the best and I >> > think only valid way of checking if callsite/callee is hot >> (isHotCount()). >> > There are 2 solutions that I come up with Teresa and Easwaran: >> > >> > 1. Add PGO data to summary >> > 2. Replace CalleeInfo::Pro...