similar to: [LLVMdev] ProfileEstimator inconsistency

Hi, I have a problem with the following scenario: I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifierPass. This is what

Hi all, In light of the expected removal of ProfileInfo this is a request for comments on the next few items that I now plan to work on for GSoC. Planned tasks: #0 Add support for determining branch weight metadata by profiling At the absolute minimum this will require writing a new profile loader which will set branch weight metadata based on profiling data. #1 Optionally use profiling

Hi all, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html I implemented the algorithm presented in [Ball94]. It only instruments the minimal number of edges necessary for edge profiling. The main changes introduced by this patch are: *) a interface compatible rewrite of ProfileInfo *) a cleanup of ProfileInfoLoader (some functionality in ProfileInfoLoader

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

Hi Andreas, First, thanks again for undertaking this work and submitting it back. There is a lot of good stuff here and it would be great to see it get back into the tree. I have a few major high-level comments on the patch. First off, the patch is quite large and should be broken down into separate incremental changes which are easier to review and apply. I think the patches should more or less

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, I have a problem with the following scenario: I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifierPass. This is what

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

2007/11/22, Duncan Sands <baldrick at free.fr>: > > Hi, > > > Current llvm-gcc cannot emit llvm intrinsic function like llvm.pow.* and > > llvm.sin.* > > For example: > > > > double foo(double x, double y) { > > return pow(x,y); > > } > > > > will compiled into ll: > > > > define double @foo(double %x, double %y) {

> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/12/2017 9:33 AM, Mehdi Amini via llvm-dev wrote: >>> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Mon, 9 Jan 2017 11:43:17 -0600 >>> Wei Ding via llvm-dev <llvm-dev at

Hi, > Current llvm-gcc cannot emit llvm intrinsic function like llvm.pow.* and > llvm.sin.* > For example: > > double foo(double x, double y) { > return pow(x,y); > } > > will compiled into ll: > > define double @foo(double %x, double %y) { > %tmp3 = tail call double @pow( double %x, double %y ) > ret double %tmp3 > } > > This is not

I am resubmitting this to r-bugs, since Thomas Lumley indicates that it might be an error: On Wed, 5 Jul 2000, Thomas Lumley wrote: > On Wed, 5 Jul 2000, halvorsen wrote: > > > Hola! > > > > I have the following simple function: > > > > > testcar > > function(pow){ > > ob <- glm(Pound~CG+Age+Vage,data=car,weights=No, > >

Hi Alastair, In addition to your planned tasks, you might want to put in some work to ensure branch probabilities are not lost during optimization. One known issue is LLVM optimizer can turn branchy code into switch statements and it would completely discard probability. Here is a simple example: static void func2(int N, const int *a, const int *b, int *c) __attribute__((always_inline)); void

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

Hola! I have the following simple function: > testcar function(pow){ ob <- glm(Pound~CG+Age+Vage,data=car,weights=No, subset=No>0,family=quasi(link=power(pow),var=mu^2)) deviance(ob) } But trying to run it gives: > testcar(1/2) Error in power(pow) : Object "pow" not found I have tried to use debug on testcar, but what I can find

The transformation in LibCallSimplifier::replacePowWithSqrt with respect to -Inf uses a select instruction, which based on the observed behaviour, incorporates the side effects of the unchosen branch. This means that (for pow) a call to sqrt(-Inf) is materialized. Such a call is specified as having a domain error (C17 subclause 7.12.7.5) since the operand is less than zero. Contrast this with

OK, I have made a little search about this "problem" that apparently occurs only on Windows platform... (but I am sure most of you are already aware of it): the slow down is due to the adoption of a different algorithm for pow in mingw 3.x. This is motivated by some other changes in mingw. Here is a quote of Danny Smith that did this change: >When mingw changed default FPU settings

Hi everyone, I am trying to install colorspace (needed as part of my favourite ggplot2) on R v 2.7.0 running under ubuntu 7.04. The package is provided as source files and the compilation fails as below. I suspect this might be a problem with gcc v3/v4 incompatibility (or anything else), but I don't really know how to resolve it. Any advice will be appreciated - or perhaps somebody has got

Sorry - I misread your example and the problem. I see now where LibCallSimplifier creates the select...but we are immediately erasing that select with the code from the godbolt example. Does the real motivating case have no uses of the pow() result value? On Mon, Sep 14, 2020 at 1:03 PM Sanjay Patel <spatel at rotateright.com> wrote: > Yes, I mean just bail out on the transform in >

> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, 9 Jan 2017 11:43:17 -0600 > Wei Ding via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> I want an efficient way to implement function pow in LLVM instead of >> invoking pow() math built-in. For algorithm part, I am clear for the