similar to: [LLVMdev] Helping the optimizer along (__assume)

On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > As part of our PHP compiler (phpcompiler.org), it would be great to be > able to annotate our generated C code with, for example, (var != > NULL), or (var->type == STRING), and have that information passed > around (esp interprocedurally at link-time) by the LLVM optimizers. For some odd reason I was thinking this was going to be

Doesn't llvm-gcc support GCC's builtin_expect? Or does it transform it into nothing? On Wed, Oct 22, 2008 at 6:28 PM, Paul Biggar <paul.biggar at gmail.com> wrote: > Hi, > > I'm interested in whether or not there is a way of providing > source-level annotations to help LLVM with optimizations, similar to > VisualC++'s __assume facility >

Mike Stump wrote: > On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > >> As part of our PHP compiler (phpcompiler.org), it would be great to be >> able to annotate our generated C code with, for example, (var != >> NULL), or (var->type == STRING), and have that information passed >> around (esp interprocedurally at link-time) by the LLVM optimizers. >>

Hi Danny, On Thu, Oct 23, 2008 at 8:16 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > Doesn't llvm-gcc support GCC's builtin_expect? > Or does it transform it into nothing? This isnt the same as GCC's builtin-expect, to my knowledge. Builtin_expect will leave branch prediction hints, but won't remove the branch. This would remove the branch. There was a

On Wed, Oct 22, 2008 at 3:28 PM, Paul Biggar <paul.biggar at gmail.com> wrote: > Hi, > > I'm interested in whether or not there is a way of providing > source-level annotations to help LLVM with optimizations, similar to > VisualC++'s __assume facility > (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx). No, nothing of the sort exists. There have been some

> > %cond = i1 ... > > br i1 %cond, label %always, label %never > > never: > > call void @llvm.abort() > > unreachable > > > > At codegen time @llvm.abort() can be lowered to > > nothing at all. I'm not saying that this is my > > favorite solution, but it is simple. > > How is this different than just branching to unreachable?

On Oct 22, 2008, at 10:45 PM, Duncan Sands wrote: >> Can't you implement __builtin_assume(cond) to codegen to something >> like: >> >> %cond = i1 ... >> br i1 %cond, label %always, label %never >> never: >> unreachable >> always: > > The code generators will remove the branch to %never. > I already tried this :) What would work is

On 2008-10-22, at 19:24, Mike Stump wrote: > On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > >> As part of our PHP compiler (phpcompiler.org), it would be great to >> be able to annotate our generated C code with, for example, (var != >> NULL), or (var->type == STRING), and have that information passed >> around (esp interprocedurally at link-time) by the

> Can't you implement __builtin_assume(cond) to codegen to something like: > > %cond = i1 ... > br i1 %cond, label %always, label %never > never: > unreachable > always: The code generators will remove the branch to %never. I already tried this :) What would work is to define an llvm.abort intrinsic, and do: %cond = i1 ... br i1 %cond, label %always, label

On Oct 22, 2008, at 5:47 PM, Kenneth Boyd wrote: > One generalization I would like to see (perhaps after spending enough > time to understand how to safely inject attributes or _Pragma via > macros) is how to make an assert generate syntax errors when it is > provably violated even in release mode. I like this idea. Sounds good. One can imagine enrolling static analysis and

Hi, > * Mark the instructions used for assumptions explicitely, so they won't get > modified, i.e.: > > %cond = icmp ne i32 %p, 0 > call void @llvm.assume( i1 %cond ) gcc uses the equivalent of: %p2 = call @llvm.assume(i32 %p, "ne", i32 0) with %p2 being used for %p wherever this assumption if valid (for example in the "true" branch of an

Cédric Venet wrote: >> Technically, yes, but we can reword future standards to have the >> latitude to give compilation errors for conditions that can be proved >> to be false, then the implementation is conforming. We could always >> have a flag to control the behavior if people want/need it, though, I >> can't hardly see why they'd want it to

On Oct 22, 2008, at 5:36 PM, Gordon Henriksen wrote: > Can't you implement __builtin_assume(cond) to codegen to something > like: > %cond = i1 ... > br i1 %cond, label %always, label %never > never: > unreachable > always: The thing I don't like about this, is that this has conditional branches all over the place, which break up basic blocks, which, if you

> Technically, yes, but we can reword future standards to have the > latitude to give compilation errors for conditions that can be proved > to be false, then the implementation is conforming. We could always > have a flag to control the behavior if people want/need it, though, I > can't hardly see why they'd want it to compile if they assert > something that

Kenneth Boyd a écrit : > Cédric Venet wrote: >> you never seen assert(0 && "Not yet implemented"); ? >> You may want to compile a program like this :) >> > As I see it, under the proposed extension a compile-time false constant > would error "if the code commits to executing it". > > Heuristically, something like > > void

Hi all, I've been thinking about this issue as well, since I'm working with a architecture that can do hardware based loops, but only when the loop count is more than some minimal value. To probably use this, we need some way for the code to specify that a loop variable has a minimum value. > Can't you implement __builtin_assume(cond) to codegen to something like: > >

On Fri, Apr 22, 2016 at 10:39 AM, Philip Reames <listmail at philipreames.com> wrote: > > > On 04/22/2016 09:20 AM, Sanjay Patel via llvm-dev wrote: > > I've proposed removing the llvm.expect intrinsic: > http://reviews.llvm.org/D19300 > > The motivation for this change is in: > http://reviews.llvm.org/D19299 > > For reference: > 1. We created an

I've proposed removing the llvm.expect intrinsic: http://reviews.llvm.org/D19300 The motivation for this change is in: http://reviews.llvm.org/D19299 For reference: 1. We created an intrinsic that's only reason for existing is to improve perf, but the intrinsic can harm optimization by interfering with transforms in other passes. 2. To solve that, we created a pass to always transform

Hello folks, I think I've fixed everything left to be fixed in block placement, and I would really like for it to be on by default in 3.1: 1) I've been testing this as thoroughly as I can across a large amount of real-world code, so it shouldn't be too flaky. 2) The code has been checked in and reviewed previously. 3) It completes a significant missing feature in LLVM with

( I don't know if it's allowed to ask such question, if not, please remind me. ) I know Intel implemented several static branch prediction mechanisms these years: * 80486 age: Always-not-take * Pentium4 age: Backwards Taken/Forwards Not-Taken * PM, Core2: Didn't use static prediction, randomly depending on what happens to be in corresponding BTB entry , according to agner's