similar to: [LLVMdev] Instruction combiner: converting arithmetic into bit operations

On Oct 17, 2012, at 8:31 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > I've noticed that for a while, the instruction combiner would convert certain arithmetic operations (like + or *) into bit-manipulation operations. Specific example I have in mind is converting "2*x+1" into "(x<<1)|1". What is the intention of doing this? We want a

On 10/17/2012 11:57 AM, Chris Lattner wrote: > > We do want one canonical form, but it would be an interesting experiment to see what happens when we turned 'or' into 'add' instead of the other way around. We'd have to make sure that simplifydemandedbits and friend can handle the add case as well as the or case, but I think it is already close to smart enough to do that.

On 9/21/07, Christopher Lamb <christopher.lamb at gmail.com> wrote: > ISel patterns are matched against DAGs before register allocation. So you > are correct that ISel patterns can't take into account register classes. The > register classes in the patterns are a selection constraint for the register > allocator if that instruction is chosen, not a constraint on choosing

On Sep 22, 2007, at 4:05 AM, Andreas Fredriksson wrote: > On 9/21/07, Christopher Lamb <christopher.lamb at gmail.com> wrote: > >> ISel patterns are matched against DAGs before register allocation. >> So you >> are correct that ISel patterns can't take into account register >> classes. The >> register classes in the patterns are a selection

Look at this silly function: $ cat small.c unsigned f(unsigned a, unsigned *p) { unsigned x = a/4; p[0] = x; p[1] = x+x; return p[1] - 2*p[0]; } GCC turns this into straightforward code and figures out the 0 return value: shrl $2, %edi movl %edi, (%rsi) addl %edi, %edi movl %edi, 4(%rsi) movl $0, %eax ret LLVM optimizes the code: $ clang -O -S -o- small.c -emit-llvm define i32

Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to 0-sNaN then though or does that not signal? Does that mean we need a separate way to handle negate in the IR? Funnily enough, historically I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at least). Is there a good reason why multiplication by NaN should kill

Ok. That you for clarifying the point for me. I was primed for a regression because this behavior changed over llvm versions and was causing my tests to fail ;). I'm now doing bitcasting to int, xoring with the signbit and bitcasting back. On Thu, Aug 7, 2014 at 2:59 AM, Owen Anderson <resistor at mac.com> wrote: > Subtraction is also not a correct implementation of negation, for

Hi, We have recently published a paper on floating point accuracy analysis through Monte Carlo Arithmetic. We also released the open-source tool Verificarlo (https://github.com/verificarlo/verificarlo) that relies on LLVM for instrumenting floating point operations. Could you please add our paper to http://llvm.org/pubs/ ? Verificarlo: checking floating point accuracy through Monte Carlo

To the R development team: First of all, thank you so much for maintaining wonderful R software. Perhaps, Dr. Ahn has just reported an error on the wilcox.test() function, and suggesting that an error may arise from abs() and rank(). I just had a quick check that the problem may come from the precision of the results of arithmetic functions. 87.7-89.1+1.4 # > 87.7-89.1+1.4 # [1]

On Tue, Apr 17, 2012 at 1:36 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > I am not sure how best to fix this. If possible, InstCombine's > canonicalization shouldn't hide arithmetic progressions behind bit masks. > At least, it seems these transformations should be disabled unless (X >> > C).hasOneUse(). They aren't exactly optimizations.

Dear All,   is there a function in R that would help me convert a covariance matrix built based on arithmetic returns to a covariance matrix from log-returns?   As an example of the means and covariance from arithmetic:   mu <-c(0.094,0.006,1.337,1.046,0.263) sigma

On the help page "DateTimeClasses {base}" it says: "One can add or subtract a number of seconds or a difftime object from a date-time object, but not add two date-time objects." However, > x<-Sys.time(); y<-Sys.time()+3600 > diff<-y-x > x; y; diff [1] "2005-11-23 19:58:20 GMT" [1] "2005-11-23 20:58:20 GMT" Time difference of 1 hours

> I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) I think it's probably safe for IEEE754-2008 conformant platforms because negation was clarified to be a non-arithmetic bit flip that cannot cause exceptions in that specification. However, I'm sure

In r187314, APFloat multiplication by with NaNs was made to always yield a positive NaN. I am wondering whether that was the correct decision. It is of course true that the result of a multiplication is undefined in IEEE, however, we were using multiplication by -1.0 to implement IEEE negate, which is defined to preserve the sign bit. r210428 made 0-NaN have IEEE negate behavior, which is good

Dear Martin, Have you try to create a new variable for age squared, say agesq? If you fit the model using this new variable you should get the coefficients. So your new model is something like height~age+agesq I hope this helps, Saghir > -----Original Message----- > From: MARTIN Ludovic [SMTP:martinl@mathinfo.ens.univ-reims.fr] > Sent: Wednesday, 07 May, 2003 2:02 PM > To:

Attached warnings from clang 7.0 when compiling child-wait.c from dovecot 2.3.5: "arithmetic on a null pointer treated as a cast from integer to pointer is a GNU extension [-Wnull-pointer-arithmetic]". -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190318/a5b5d2d4/attachment.html> --------------

I would also be interested in fixed-point arithmetic support in clang/llvm? Is there any movement on this direction since August? Regards, Pedro Malagon -- Pedro Malagon Dpt. Electrical Engineering - Technical University of Madrid Assistant Professor Office B-113 Avda. Complutense s/n, 28040 Madrid Tel. (+34) 915495700 ext. 4220 @:malagon at die.upm.es On 08/10/2013 09:24 PM, Giorgio

Good point. The same argument seems to apply to copy() too so I suppose it depends how strict we want to be about it. From: fglaser at apple.com [mailto:fglaser at apple.com] On Behalf Of escha at apple.com Sent: 11 April 2016 20:55 To: Daniel Sanders Cc: Alex Rosenberg; llvm-dev at lists.llvm.org; Carlos Liam Subject: Re: [llvm-dev] Implementing a proposed InstCombine optimization On Apr 11,

FYI, we are also interested. (But our limited staff are currently busy just getting our LLVM backend out of the door (in-house only). I hope we will have time to look at this in a year or so.) Regards, Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Pedro Malagon Sent: den 3 december 2013 14:30 To: llvmdev at

Hi, Is there anyone else interested in fixed-point arithmetic support in clang/llvm? Regards, Sergey On Sat, Aug 3, 2013 at 12:14 AM, Sergey Yakoushkin < sergey.yakoushkin at gmail.com> wrote: > Hi all, > > Were there any further discussion or progress with the fixed point support > (ISO/IEC TR 18037) in the meantime? >