similar to: [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

Hi Reid - The intent of D19299 is to remove all Clang refs to llvm.expect. Do you see any holes after applying that patch? On Fri, Apr 22, 2016 at 11:36 AM, Reid Kleckner <rnk at google.com> wrote: > Clang still appears to use llvm.expect. I think if you can show that it's > trivial to update clang with a patch, then yeah, moving back down to one > representation for this

I, of course, thought the ~100 lines added by D19299 was a reasonable trade for the ~800 lines removed in D19300. David Li (and anyone else following along), do you still like those patches after hearing this objection or should I abandon? On Fri, Apr 22, 2016 at 11:55 AM, Reid Kleckner <rnk at google.com> wrote: > Sorry, I didn't realize that was the clang side. > > I think

Sorry for jumping in so late into this discussion, but I genuinely believe that removing this is a bad idea. My reason for saying this is going to sound very strange, but I think that we need to understand a bit more about how this is being handled. A while back one of my customers asked me if there was a method for advising the compiler how an if-statement was likely to resolve, and I

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 everyone, I am looking at a way to mark part of a source code for an optimisation pass (or how to transfert information from source code to IR). I want to work on C / C++ / Objective-c and Swift. Something like: ... //Begin Optimisation if(i % 2){ printf(“Something”); } //End Optimisation for(int i = 0; i < 10; ++i){ printf("%d, “, i); } printf("\n”); … I have found

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 >

Hey all, I'd like to propose a new intrinsic for use in preventing optimizations from deleting IR due to constant propagation, dead code elimination, etc. # Background/Motivation In Rust we have a crate called `test` which provides a function, `black_box`, which is designed to be a no-op function that prevents constprop, die, etc from interfering with tests/benchmarks but otherwise

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

I performed tests basing on first diff of https://reviews.llvm.org/D40352. (Creates .eh_frame for each .text.*, sets SHF_LINK_ORDER and .sh_link of created .eh_frame section to point to corresponding .text.) With use of GNU ld (GNU Binutils) 2.29.51.20171006 it reports errors when linking sample apps: ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o /usr/local/bin/ld: .eh_frame

> Thanks for the details. Please add them to a bug report. I will do this. > InstCombine is certainly interfering with our ability to analyze the loop. I think the problem is that ScalarEvolution cannot reason about signed division. This is a general problem independent of your target. At the moment I'm not sure if we can teach ScalarEvolution to reason about this, or if we can defer

Hi everyone, Sergey (CC’ed) worked on a series of patches to add support for floating-point environment and floating-point rounding modes in LLVM. This started *in 2014* and the patches after multiple rounds of review in the last months (involving amongst other Steve Canon, Hal Finkel, David Majnemer, and myself) are getting very close (IMO) to be in a state where we can land them. This is the

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

>Keeping .eh_frame separated should still simplifies the linker because >until the last step of building .eh_frame and .eh_frame_hdr, we don't >really need to parse .eh_frame sections. So, if we have separate .eh_frame >sections on -ffunction-sections, all we have to do is (1) garbage-collect >sections and (2) construct .eh_frame and .eh_frame_hdr sections from live

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 Feb 7, 2013, at 10:53 AM, Michele Scandale <michele.scandale at gmail.com> wrote: >> Thanks for the details. Please add them to a bug report. > > I will do this. Thanks. >> InstCombine is certainly interfering with our ability to analyze the loop. I think the problem is that ScalarEvolution cannot reason about signed division. This is a general problem independent of

Hi Chandler, This scheme has significant advantages over what was being pursued, but one question (or two)... Under the proposed system, how would you represent the necessary dependency edges between the fp intrinsics and function calls? How is the state 'returned' to the caller? [I was thinking that our new operand bundles could help for the inputs, but the outputs? Plus what about the

>> With GNU gold (GNU Binutils 2.29.51.20171006) 1.14 have an assert: >> ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o >> /usr/local/bin/ld: internal error in layout_eh_frame_section, at >> .././../gold/object.cc:1309 >> It is that place: >> https://github.com/gittup/binutils/blob/gittup/gold/object.cc#L1372 >> Did not investigate it,

On Apr 15, 2012, at 6:42 PM, Chandler Carruth wrote: > 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