similar to: Why did Intel change his static branch prediction mechanism during these years?

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 >

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

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

Èç¹û±¾Óʼþ¸øÄã´øÀ´Á˲»±ã£¬ÎÒÃÇÉî¸Ð±§Ç¸£¬ÇëÁ¢¼´°ÑËüɾ³ý£¬ ²¢À´ÐÅ˵Ã÷£¬ÎÒÃǽ«²»»áÔٴδòÈÅ¡£ ͨÓÃÍøÖ·-----Ö±½ÓÊäÈëÆóÒµ¡¢²úÆ·¡¢ÍøÕ¾µÄÃû³Æ£¬¼´¿ÉÖ±´ïÄ¿±êÍøÕ¾.ÎÞÐè¼ÇÒ临ÔÓ µÄÓòÃû¡¢ÍøÖ·£¬ÎÞÐèhttp://¡¢www ¡¢.com¡¢.netµÈÇ°ºó׺ ÊǼÌIP¡¢ÓòÃûÖ®ºó£¬×îÏÈ ½ø¡¢×î¿ì½Ý¡¢×î·½±ãµÄµÚÈý´ú»¥ÁªÍø·ÃÎʱê×¼ ¡£ÔÊÐí¸öÈË×¢²á£¬¿ª·Å ͨÓôʻã×¢²á²¢¿É×ÔÓÉתÈã¬ÉÌ»úÎÞÏÞ£¡¡°Í¨ÓÃÍøÖ·¡±ÔÚÏß×¢²á£¬Ãâ·ÑÊÔÓÃÊ®Ì죬24

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

I have installed radRails V0.6.1 When i tried to press ctrl+backspace in editor ,the error come up "Ruby Content Assist did not complete normaly.please see the log for moreinformation." what sould i do to solve this error ? thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

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

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Herbie Robinson > Subject: Re: [LLVMdev] [RFC] [X86] Mov to push transformation in x86-32 call sequences > > On 12/21/14 4:27 AM, Kuperstein, Michael M wrote: > > Which performance guidelines are you referring to? > Table C-21 in "Intel(r) 64 and IA-32 Architectures

hello- i am using rsync via ssh to maintain a copy of a few directories on a remote server, and am getting an error when rsync tries to chmod a certain file following it's transfer. there are a couple of cases in which this occurring - below is one example. local machine is debian testing - rsync version 2.6.3 protocol version 28 remote machine is macos x 10.3.7 - rsync version 2.6.2

We have an LDAP server that contains AES encrypted passwords. So far I've been able to use this by adding a passdb module that encrypts the user's password prior to ldap comparison. Now I am looking at supporting client-side encrypted passwords. To do this I need to decrypt the password returned by LDAP. Is there a way to insert a module to do this decryption between ldap returning and

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

hello- i was messing around with a did from ipkall.com, and asterisk seems to be ignoring the context specified in the sip config. in sip.conf, i've added: [7508] ;ipkall type = peer dtmfmode = rfc2833 context = remote callerid = "ipkall incoming" <7508> nat = no in extensions,conf, i have: [remote] exten => 7508,1,DISA(1111|internal) [internal] exten =>

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

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

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

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

On 08/31/2015 03:59 PM, Matthias Braun wrote: > Looks to me like the alignment is specified in tablegen. From Target.td: > > class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, > dag regList, RegAltNameIndex idx = NoRegAltName> > > X86RegisterInfo.td: > > def VR256 : RegisterClass<"X86", [v32i8,

Two other things: 1) I get massively more stable execution times on 16.04 than on 14.04 on both x86 and ARM because 16.04 does far fewer gratuitous moves from one core to another, even without explicit pinning. 2) turn off ASLR: "echo 0 > /proc/sys/kernel/randomize_va_space". As well as getting stable addresses for debugging repeatability, it also stabilizes execution time

Hi, We are currently working on revising a journal article that describes our work on pre-allocation scheduling using LLVM and have some questions about LLVM's pre-allocation scheduler. The answers to these question will help us better document and analyze the results of our benchmark tests that compare our algorithm with LLVM's pre-allocation scheduling algorithm. First, here is a