search for: __assume

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 rough discussions of what would be involved, but there isn't really a plan for how to implement it. It would probably end up being similar to TBAA. -Eli

...oes 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 > (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx). > > 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 &gt...

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

...gt; assert (or a special no code generating assert). Just gen up assert > (i != 0); and put it in anytime it is true. The optimizers in the > fulness of time would the recognize and propagate this information. > The Microsoft implementation is scary. I'd be much happier with __assume if it caused a syntax error in the misprint example given. 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...

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

> 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

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

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

> 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

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

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

..., When clang/llvm compiles the following sample (with -O2) it optimizes away the second comparison in test1 but not in test2. Is this handling of 'unreachable' by purpose, or is this just a shortcoming of the current optimization passes? GCC and MSVC (with the equivalent code using the __assume intrinsic) both optimize away the comparison in test2. void f1(); void f2(); void abort() __attribute__((noreturn)); void test1(int x) { if (x < 0) abort(); // the following comparison is optimized away if (x < 0) f1(); else f2(); } void test2(int x) { if (x < 0) __builti...

...read, as a follow-up to several older ones, on > > invariants in LLVM. Fundamentally, invariants are conditions that > > the optimizer is allowed to assume will be valid during the > > execution of the program. Many other compilers support a concept > > like this, MSVC's __assume, for example. GCC has a builtin called > > __builtin_assume_aligned which also neatly falls into this class. > First of all, thank you for working on this! I'm thrilled to see > progress being made here. > > > > In my initial patches, I've named the associated IR-le...

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

...llo everyone, I'm starting a new thread, as a follow-up to several older ones, on invariants in LLVM. Fundamentally, invariants are conditions that the optimizer is allowed to assume will be valid during the execution of the program. Many other compilers support a concept like this, MSVC's __assume, for example. GCC has a builtin called __builtin_assume_aligned which also neatly falls into this class. In my initial patches, I've named the associated IR-level intrinsic @llvm.invariant(i1) (maybe it should be @llvm.assume, etc. -- please feel free to express an opinion). I'll attempt...