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

Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] Helping the optimizer along (__assume)"

2008 Oct 22
0
[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
2008 Oct 23
0
[LLVMdev] Helping the optimizer along (__assume)
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 >
2008 Oct 23
2
[LLVMdev] Helping the optimizer along (__assume)
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. >>
2008 Oct 23
1
[LLVMdev] Helping the optimizer along (__assume)
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
2008 Oct 22
0
[LLVMdev] Helping the optimizer along (__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
2008 Oct 23
0
[LLVMdev] Helping the optimizer along (__assume)
> > %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?
2008 Oct 23
3
[LLVMdev] Helping the optimizer along (__assume)
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
2008 Oct 23
8
[LLVMdev] Helping the optimizer along (__assume)
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
2008 Oct 23
0
[LLVMdev] Helping the optimizer along (__assume)
> 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
2008 Oct 23
0
[LLVMdev] Helping the optimizer along (__assume)
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
2008 Oct 23
1
[LLVMdev] Helping the optimizer along (__assume)
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
2008 Oct 23
0
[LLVMdev] Helping the optimizer along (__assume)
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
2008 Oct 23
0
[LLVMdev] Helping the optimizer along (__assume)
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
2008 Oct 23
3
[LLVMdev] Helping the optimizer along (__assume)
> 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
2008 Oct 23
1
[LLVMdev] Helping the optimizer along (__assume)
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
2008 Oct 23
0
[LLVMdev] Helping the optimizer along (__assume)
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: > >
2016 Apr 22
3
[RFC] remove the llvm.expect intrinsic
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
2016 Apr 22
4
[RFC] remove the llvm.expect intrinsic
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
2012 Apr 16
2
[LLVMdev] Switching the new block placement pass on by default for 3.1
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
2018 Aug 14
4
Why did Intel change his static branch prediction mechanism during these years?
( 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