similar to: Status update on the hot/cold splitting pass

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

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

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

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

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

> Just chiming in about the outliner stuff. (In general, I think it's desirable to have multiple options for how early/late a pass runs.) I'm wondering if MachineOutliner can be augmented to add MachineFunctionSplitter functionalities as well. If the analysis part of MachineOutliner can allow single basic block outlining with some cost models. Aditya Kumar Compiler Engineer

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

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

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

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

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

On Wed, 9 Sep 2020 at 14:27, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > A more aesthetic comment I have is that personally, I would prefer a > single option with a default percentage (say 0%) rather than having to > specify two options. > 0% doesn't mean "don't do it", just means "only do that to functions I didn't see running at

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1323432076 0 # Node ID 9c1b223e152eaaa3861f9b6132590de0b4f6cb7e # Parent d8c390192ad1147d7202cf04be090478f1810a5d libxl: fix cold plugged PCI devices with stubdomains Since 23565:72eafe80ebc1 the xenstore entries for the stubdomain''s PCI were never created and therefore the stubdom ends up waiting forever

Hello, We use PGO to optimize clang itself. I can see if I have time to give this patch some testing. Anything special to look out for except compile benchmark and time to build clang, do you expect any changes in code size? On Wed, Sep 9, 2020, 10:03 Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, 9 Sep 2020 at 01:21, Min-Yih Hsu via llvm-dev < >

Convey uses a highly modified CentOS kernel to work with our attach coprocessor. Currently to setup a system for delivery we do a cold install using a "stock" CentOS cold install using kickstart. During that cold install we lay down our modified kernel and reboot the system with that kernel. After the reboot we are able to access the coprocessor management processor and down

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

FYI David is referring to PGSO (profile-guided size optimization) as it exists directly under that name, see: https://reviews.llvm.org/D67120. And yeah using PGSO is selecting optsize while this change is selecting optnone. On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org> on

Am 19.06.2017 um 11:42 schrieb Winfried via samba: > ### BEGIN INIT INFO > # Provides: samba > # Required-Start: > # Required-Stop: > # Default-Start: > # Default-Stop: > # Short-Description: ensure Samba daemons are started (nmbd and smbd) > ### END INIT INFO well, there is no ordering with network services most likely your samba starts before the network is