similar to: [LLVMdev] machine branch probability info

On Jun 1, 2011, at 5:03 PM, Jakub Staszak wrote: > I just found a small bug. Fixed version attached. > > <kuba_bp3.patch> Committed as r132613 (and r132616). Thanks Jakub! To help reviewers understand the patch and where we're headed with it, I've prepared the following design documentation. For now I'm sending it to llvm-dev until we have an official design doc for

Hi RamShankar, On top of Rafael mentioned ,Please check with lib/CodeGen/StrongPHIElimination.cpp and the papers like Budimlic, et al. Fast copy coalescing and live-range identification. // In Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language // Design and Implementation (Berlin, Germany, June 17 - 19, 2002). // PLDI '02. ACM, New York, NY, 25-32. Boissinot,

Hi, I am a newbie to llvm. I am wondering what approach is used when coming out of SSA form. I also appreciate pointers on where to look in the source code for this phase. Best regards, Ram Ramshankar -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120824/87feb1d3/attachment.html>

On 24 August 2012 02:27, Ramanarayanan, Ramshankar <Ramshankar.Ramanarayanan at amd.com> wrote: > Hi, > > > > I am a newbie to llvm. I am wondering what approach is used when coming out > of SSA form. I also appreciate pointers on where to look in the source code > for this phase. > lib/CodeGen/PHIElimination.cpp is probably what you want. > > Best regards,

On Fri, Apr 24, 2015 at 12:29 PM, Diego Novillo <dnovillo at google.com> wrote: > > > On Fri, Apr 24, 2015 at 3:28 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> yes -- for count representation, 64 bit is needed. The branch weight >> here is different and does not needs to be 64bit to represent branch >> probability precisely. > >

----- Original Message ----- > From: "Adam Nemet" <anemet at apple.com> > To: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Saturday, January 17, 2015 12:20:55 AM > Subject: Re: [LLVMdev] proof of concept for a loop fusion pass > > > On Jan 15, 2015, at 4:22 PM, Ramanarayanan,

Hello :) I am looking around __builtin_expect() directive for optimization. ( http://llvm.org/docs/BranchWeightMetadata.html ) Since it is not included in v2.9, I am searching about it on svn trunk. I found that the lowering phase generates branch-weight metadata node for that directive. However, I can't find any code related to the metadata even in the branch transformation code. IMHO, in

Hi, We are proposing a loop fusion pass that tries to proactive fuse loops across function call boundaries and arbitrary control flow. http://reviews.llvm.org/D7008 With this pass, we get 103 loop fusions in SPECCPU INT 2006 462.libquantum with rate performance improving close to 2.5X in x86 (results from AMD A10-6700). I took some liberties in patching up some of the code in

If -simd option is specified opt could do validity checks, dependency analysis and such and recognize that a loop can be executed in parallel and as the -simd option is specified, convert the data types to vector instructions and add the scaling factor to the loop's iterators. Following this there can be an early machine function pass that sets up processor specific value in all of

----- Original Message ----- > From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Dibyendu Das" <Dibyendu.Das at amd.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 11:00:39 AM > Subject: RE: [LLVMdev]

On Wed, Aug 29, 2012 at 12:11 AM, Ramanarayanan, Ramshankar <Ramshankar.Ramanarayanan at amd.com> wrote: > I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining is > done first on each file and then at linking phase. Wouldn’t it be a better > alternative to delay inlining decisions until the link stage? Yes and no. Yes in the sense that you may make some better

I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining is done first on each file and then at linking phase. Wouldn't it be a better alternative to delay inlining decisions until the link stage? Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120829/dda45c1c/attachment.html>

On Tue, Aug 28, 2012 at 10:39 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Wed, Aug 29, 2012 at 12:11 AM, Ramanarayanan, Ramshankar > <Ramshankar.Ramanarayanan at amd.com> wrote: > > I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining > is > > done first on each file and then at linking phase. Wouldn’t it be a > better > >

> On Mar 24, 2015, at 10:27 AM, Xinliang David Li <davidxl at google.com> wrote: > > Diego and I have discussed this according to the feedback received. We > have revised plan for this (see Diego's last reply). Here is a more > detailed re-cap: > > 1) keep MD_prof definition as it is today; also keep using the > frequency propagation as it is (assuming programs

Greetings, I have a very, very, simple research question. I want to predict one dichotomous variable using another dichotomous variable. Straightforward, right? The issue is that the dataset has two issues causing some complications for me. 1) The subjects are not independent -- they are sibling pairs. Every person in the dataset has a sibling in the dataset. This needs to be treated a

Adding Maxim On Apr 9, 2018, at 10:06 AM, Sam Parker via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi, extractRangeChecksFromBranch uses BranchProbabilityInfo to decide whether its worth trying the InductiveRangeCheckElimination transformation. For the following example: void split() { for (int i = 0; i < 100; ++i) { if (i < 99)

Hi, extractRangeChecksFromBranch uses BranchProbabilityInfo to decide whether its worth trying the InductiveRangeCheckElimination transformation. For the following example: void split() { for (int i = 0; i < 100; ++i) { if (i < 99) do_something() else do_something_else() } } But the reported BPI is reported as 50/50 to whether do_something will be called, but we

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

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

Hi Andrew, > Representation: 32-bit unsigned int stored in IR meta-data. why store it in the IR, and not just have it be an analysis that you can query for branch probabilities? If you store it in the IR then it may well get out of date (eg: when an optimizer realizes that some branches is dead and deletes it, resulting in probabilities that don't add up to 1 on the other branches). This