search for: colde

Greetings, We present “Machine Function Splitter”, a codegen optimization pass which splits functions into hot and cold parts. This pass leverages the basic block sections feature recently introduced in LLVM from the Propeller project. The pass targets functions with profile coverage, identifies cold blocks and moves them to a separate section. The linker groups all cold blocks across functions

On Tue, Feb 5, 2019, 3:46 PM Vedant Kumar <vedant_kumar at apple.com> wrote: > Hi Teresa, > > On Feb 5, 2019, at 2:38 PM, Teresa Johnson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > > On Mon, Jan 28, 2019 at 11:03 AM Aditya K via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > The splitting pass currently doesn’t

The splitting pass currently doesn’t move cold symbols into a separate section. Is that affecting your results? On Darwin, we plan on using a symbol attribute to provide an ordering hint to the linker (see r352227, N_COLD_FUNC). vedant > On Jan 28, 2019, at 10:51 AM, Aditya K via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Very happy to see good results. On our side, we are

Hello, I’d like to give a status update to the community about the recently-added hot/cold splitting pass. I'll provide some motivation for the pass, describe its implementation, summarize recent/ongoing work, and share early results. # Motivation We (at Apple) have found that memory pressure from resident pages of code is significant on embedded devices. In particular, this pressure spikes

On Mon, Jan 28, 2019 at 11:03 AM Aditya K via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > The splitting pass currently doesn’t move cold symbols into a separate > section. Is that affecting your results? > Maybe partly, the main reason is that, in the absence of good profile > info, we aren't finding many cold blocks. > We noticed that the split cold functions

Hello, I am Ruijie Fang, a GSoC student working on "Improve hot cold splitting to aggressively outline small blocks." Over the course of last week, I met with my mentor and co-mentor, Aditya Kumar, and Rodrigo Rocha, and we made a preliminary plan on improving the existing hot/cold splitting pass in LLVM through identifying patterns of cold blocks in real-world workloads via block

>Exceptions >All eh pads are grouped together regardless of their coldness and are part of the original function. There are outstanding issues with splitting eh pads if they reside in separate sections in the binary. This remains as part of future work. Can you elaborate more on the outstanding issues with splitting eh pads? From my dip into the unwind map in gcc_except_table the

On Tue, Aug 4, 2020 at 10:51 PM aditya kumar <hiraditya at gmail.com> wrote: > Glad to hear that there is an interest in a function splitting pass. There > are advantages to splitting functions at different stages as you've already > noted. > Right -- with slightly different objectives. Machine Function Splitting Pass's main focus is on performance improvement. > -

Does anyone have any ideas about how to fix, or to work-around the following issue? Thanks! Bug 1549714 - On sharded tiered volume, only first shard of new file goes on hot tier. https://bugzilla.redhat.com/show_bug.cgi?id=1549714 On sharded tiered volume, only first shard of new file goes on hot tier. On a sharded tiered volume, only the first shard of a new file goes on the hot tier, the rest

On Wed, 9 Sep 2020 at 19:26, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > - Default (i.e. no -profile-deopt-cold): do nothing > - Option with no arg (i.e. -profile-deopt-cold): add attribute only to > functions that have an execution count of zero > - Option with an arg (i.e. -profile-deopt-cold=<N>): add attribute to > functions that account for <N>% of

Hi Teresa, Thank you for your reply! I discussed this with Aditya and Rodrigo today about this. We will always have PGO turned on for our benchmark, (i.e. we assume the profiling information is always available). In terms of the workload we supply to PGO: For postgresql, I suggested we use the "pgbench" benchmark, a TPC-B-based SQL benchmark for postgres, to supply profiling information

We would like to propose a new feature to disable optimizations on IR Functions that are considered “cold” by PGO profiles. The primary goal for this work is to improve code optimization speed (which also improves compilation and LTO speed) without making too much impact on target code performance. The mechanism is pretty simple: In the second phase (i.e. optimization phase) of PGO, we would add

Hello Tobias, Thank you for the suggestion! Aditya also mentioned this. I will look into it. Best regards, Ruijie Ruijie Fang Email: ruijief at princeton.edu On Tue, Jun 2, 2020 at 12:48 PM Tobias Hieta <tobias at plexapp.com> wrote: > Hello Ruijie, > > One other workload that would be interesting to test might be clang > itself. Building clang with PGO information is a

Hi Guys Got a quick question regarding hot tier and cold tier. I got a gluster volume with 1 x 3 hot tier and 1 x 3 cold tier. watermark-low is 75 and watermark-hi is 90. usage of volume is very less. My files always go to hot tier and cold tier at same time As I understand, data should go to hot tier only until demoted. Could someone please shed some light into this? Thanks in advance. --

I'm part of a team working on adding an llvm codegen backend to HHVM (PHP JIT, http://hhvm.com) using MCJIT. We have a code layout problem and I'm looking for opinions on good ways to solve it. The short version is that the memory we emit code into is split into a few different areas, and we'd like a way to control which area each BasicBlock ends up in during codegen. I know this

Hello, I've just run out of memory on a dual xeon with 5GB ram, considering there should have been around 4GB free (not counting buffers and cache)... this is unusual. Now after it OOM'ed I tried running top and memory usage was fine (around 1GB of 5, no swap usage of 12GB). So I thought it was a temporary thing, but processes kept on OOM'ing for no understandable reason... while

Hi, The actual data will be in the hot tier only till demotion. The file that you see on the cold tier is just a linkto file of the file on the hot tier. These linkto file are necessary for the internal working of the tier. On Mon, Mar 5, 2018 at 1:16 PM, Sherin George <allmyforums at outlook.in> wrote: > Hi Guys > > Got a quick question regarding hot tier and cold tier. > I

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

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

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