similar to: [LLVMdev] Assert in BlockFrequency pass

> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote: >> >> Hi, we got the following assert: >> >> assert(!Working[0].isLoopHeader() && "entry block is a loop header"); >> >> [in

In include/llvm/ADT/Statistic.h, the identifier “DEBUG_TYPE” is never defined. I’ve noticed it’s defined as different things in a few other header files, including llvm/Analysis/BlockFrequencyInfoImpl.h, llvm/Analysis/RegionInfoImpl.h, llvm/Support/UnicodeCharRanges.h, llvm/Transforms/InstCombine/InstCombineWorkList.h, and llvm/Transforms/Utils/SSAUpdaterImpl.h. Should I edit Statistic.h so that

David Is this true for static heuristics as well ? If the bb freqs are scaled wrt to the entry block freq and a) use such scaled freqs for the bb's that have calls b) propagate this info topologically over the call graph, how representative will be the info if one just wants to use in a comparative sense ? -Dibyendu Sent from my Windows Phone ________________________________ From: Xinliang

The BlockFrequency analysis has been useful for machine block placement, register allocation and other function-level optimizations. How could we extend it for use in an inter-procedural (whole-program) context? For example, if we would like to compare the hotness of two call sites in different functions, or calculate the hotness of two global variables referenced in multiple functions. If the

> Date: Tue, 14 Apr 2015 21:33:03 -0700 > From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] RFC: Metadata attachments to function definitions > Message-ID: <BF4002F0-06DC-4A25-AF84-7D21AD48121A at apple.com> > Content-Type: text/plain; charset=us-ascii > >

On 04/15/15 12:55, Duncan P. N. Exon Smith wrote: >> On 2015-Apr-15, at 08:11, Ivan Baev <ibaev at codeaurora.org> wrote: >> >>> Date: Tue, 14 Apr 2015 21:33:03 -0700 >>> From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com> >>> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >>> Subject: [LLVMdev] RFC:

On Feb 4, 2014, at 4:36 PM, Andrew Trick <atrick at apple.com> wrote: > > On Feb 4, 2014, at 4:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> On Feb 3, 2014, at 12:13 AM, Andrew Trick <atrick at apple.com> wrote: >> >>> On Feb 2, 2014, at 6:55 PM, Chandler Carruth <chandlerc at gmail.com> wrote: >>>

Hi, we've implemented an indirect call promotion llvm pass. The design notes including examples are shown below. This pass complements the indirect call profile infrastructure http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084271.html Your feedback and comments will be highly appreciated. Thanks, Ivan ============================================================================RFC:

Hello, I'm working on an application that would benefit from knowing the weight of a basic block, as in "fraction of the program's execution time spent in this block". Currently, I'm computing this using the block's frequency from BlockFrequencyInfo, relative to the function's entry block frequency, and scaled by the function's entry count. This is also the

On Sun, Jul 15, 2012 at 8:32 AM, Alastair Murray <alastairmurray42 at gmail.com > wrote: > Hi Chandler, > > I'm a GSoC student working on profiling support (mentor CC'ed). I'm no > stranger to the issues with the current system: my original proposal was > written without knowledge of the limitations. This is why this list > hasn't heard much from me yet.

Hi Chandler and Alastair, I have been using the Profile.pl and the related passes and optimizations for about 4 years now. With every new release lately, the support for the profile scripts and their framework seemed to be downgrading. Hence, I used my own tiny one line fixes to keep them working. I offered to send these small patches to keep these scripts working, to the LLVM dev so that others

Thank you so much for your response. On Wed, Aug 15, 2018 at 3:08 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Wed, Aug 15, 2018 at 7:36 AM Malhar Thakkar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hey all, >> >> I have a piece of code (written in LLVM 2.8) which uses profiling results >> produced by ProfileInfo.

Hey all, I have a piece of code (written in LLVM 2.8) which uses profiling results produced by ProfileInfo. It essentially computes the number of iterations performed by a loop from the profiling information available. The code snippet in my pass looks something like this. BasicBlock *header = loop->getHeader(); ProfileInfo &pi = getAnalysis< ProfileInfo >(); for(pred_iterator

On Wed, Aug 15, 2018 at 1:28 PM Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Wed, Aug 15, 2018 at 12:46 PM Malhar Thakkar <cs13b1031 at iith.ac.in> > wrote: > >> Thank you so much for your response. >> >> On Wed, Aug 15, 2018 at 3:08 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote: >> >>> >>>

Hi Chandler, I'm a GSoC student working on profiling support (mentor CC'ed). I'm no stranger to the issues with the current system: my original proposal was written without knowledge of the limitations. This is why this list hasn't heard much from me yet. I would like to continue working on profiling support but I'm not attached to ProfileInfo and wouldn't be

Hello, I have a question regrading the analysis pass that generates loop info from an .ll code. My previous understanding was there will be just one loop header(in the loop info) for a particular loop. But, when i use isLoopHeader() member function from the loop info class I get 'true' return value for two different basic blocks. Note both basic blocks are loop conditional block(break

On Jun 17, 2013, at 10:48 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > [Splitting this out from the original thread to reduce noise in it] > > > On 17.06.2013, at 18:43, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { >> + return (isDef + isUse) * freq.getFrequency();

[Splitting this out from the original thread to reduce noise in it] On 17.06.2013, at 18:43, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 17, 2013, at 7:03 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > >> >> On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: >> >>> On 2013-06-15 16:39 ,

Hello folks, I'd like to remove all of the old and defunct profile info passes from LLVM. These have been almost entirely supplanted by the BranchProbability and BlockFrequency systems, which are actually on by default, and in use in optimization passes. The old system is not on, and hasn't been touched in years except to do minor build fixes and updates. As far as I'm aware, the

On Mon, Jun 17, 2013 at 11:03 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > >> This computation can overflow. > > > > Yep, I went down the easy route and converted it to floating point > arithmetic. Is that OK here? > > Yes, that should be fine. I really don't think this is fine. I would like for LLVM to not rely on floating point arithmetic on