similar to: [LLVMdev] conditional assignment in selectionDAG

Hi, > Both A and B are undef: > LHS = (undef & undef) | (undef & undef) = undef // Since ~undef = undef > RHS = undef > Thus transform is correct. LLVM documentation (http://llvm.org/docs/LangRef.html#undefined-values) suggests that it is unsafe to consider (a & undef = undef) and (a | undef = undef). "As such, it is unsafe to optimize or assume

Thanks for your answers. Another example of unsound transformation on Boolean algebra. According to the LLVM documentation (http://llvm.org/docs/LangRef.html#undefined-values) it is unsafe to consider ' a & undef = undef ' and ' a | undef = undef ' but 'undef xor undef = undef' is safe. Now, given an expression ((a & (~b)) | ((~a) & b)) where a and b are

Please test if r115571 has fixed it. Evan On Oct 4, 2010, at 5:00 AM, Heikki Kultala wrote: > Bill Wendling wrote: >> On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: >> >>> Bill Wendling wrote: >>>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>>> >>>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote:

Bill Wendling wrote: > On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > >> Bill Wendling wrote: >>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>> >>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>>> >>>>> Our architecture has 1-bit boolean predicate registers. >>>>> >>>>> I've

On 11/03/2023 9:54 a.m., Sebastian Martin Krantz wrote: > Thanks Duncan, > > I know about list2env(), in fact a previous version of collapse::`%=%` > was coded as > > "%=%" <- function(lhs, rhs) { > ?? if(!is.character(lhs)) stop("lhs needs to be character") > ?? if(!is.list(rhs)) rhs <- as.vector(rhs, "list") > ?? if(length(lhs)

Thanks Duncan, I know about list2env(), in fact a previous version of collapse::`%=%` was coded as "%=%" <- function(lhs, rhs) { if(!is.character(lhs)) stop("lhs needs to be character") if(!is.list(rhs)) rhs <- as.vector(rhs, "list") if(length(lhs) != length(rhs)) stop("length(lhs) not equal to length(rhs)") list2env(`names<-`(rhs,

OK, the code for sdivrem in APInt.h is wrong. Here's what's written: static void sdivrem(const APInt &LHS, const APInt &RHS, APInt &Quotient, APInt &Remainder) { if (LHS.isNegative()) { if (RHS.isNegative()) APInt::udivrem(-LHS, -RHS, Quotient, Remainder); else APInt::udivrem(-LHS, RHS, Quotient, Remainder); Quotient =

Hi, We have implemented the rsqrt instruction generation for X86 target architecture. We have introduced a flag -fp-rsqrt flag which controls the generatation of X86 rsqrt instruction generation. We have observed minor effects on precision due to rsqrt and hence has put these transformations under the mentioned flag. Note that -fp-rsqrt is only enabled with -enable-unsafe-fp-math flag presently.

In R version 2.15.2 (2012-10-26) i386-apple-darwin9.8.0/i386 (32-bit) I get the following: > a <- list(1) > (a[[1]] <- a) [[1]] [[1]][[1]] [1] 1 but > a <- list(1) > b <- a > (a[[1]] <- a) [[1]] [1] 1 And similarly: > a <- list(x=1) > (a$x <- a) $x $x$x [1] 1 but > a <- list(x=1) > b <- a > (a$x <- a) $x [1] 1 In both cases the

This adds a bunch of static functions that implement unsigned two's complement bignum arithmetic. They could be used to implement much of APInt, but the idea is they are enough to implement APFloat as well, which the current APInt interface is not suited for. Neil. -------------- next part -------------- Index: include/llvm/ADT/APInt.h

Hi Sarath, It would have really helped if you had removed the commented out code and inlined the calls to your homemade helper functions before sending it... You are doing this, in LLVM IR: %0 = getelementptr %Value* %firstArg, i32 0 ; i8** %1 = load i8** %0 ; i8* %2 = bitcast i8* %1 to i64* %3 = getelementptr %Value* %secondArg, i32 0 ; i8** %4 = load i8** %3; i8* %5 = bitcast i8* %4 to i64*

Yeah, that's the fault...got the answer...... Thanks James for the help... Struggling with this for so many days....... On Thu, Sep 22, 2011 at 4:02 PM, James Molloy <James.Molloy at arm.com> wrote: > Hi Sarath,**** > > ** ** > > It would have really helped if you had removed the commented out code and > inlined the calls to your homemade helper functions before

Thanks to your help I've actually made some progress... Especially the SelectionDAGNodes.h was a good hint. But there are still some things that I can't figure out: // 'mov eax, 41' Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); // 'inc eax' SDValue eaxVal =

On Thu, Sep 22, 2011 at 3:46 PM, sarath chandra <sarathcse19 at gmail.com>wrote: > Hi James, > > First i converted the void * to int* and then did FPToSI...then did SHL...( > because CreateShl only accepts integers... i pointer casted it to int64 type > first)... Below is the code snippet.... > > > lhs = mBuilder.CreateStructGEP(firstArg, 0); > lhs =

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Monday, September 12, 2011 7:15 PM > To: Villmow, Micah > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Setting priority in instruction selection > > On Mon, Sep 12, 2011 at 6:53 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > I am having a problem

On Mon, Sep 12, 2011 at 6:53 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am having a problem with instruction selection with pattern fragments. > > With my custom target, in order to simplify code generation patterns, I do > not allow a constant to be used in an instruction(mainly because they have > declare before use semantics). > > > > Now the

I've been playing around with llvm lately and I was wondering something about the bitcode instructions for basic arithmetic. Is there any plan to provide instructions that perform widening multiply, or add with carry? It might be written as: mulw i32 %lhs %rhs -> i64 ; widening multiply addw i32 %lhs %rhs -> i33 ; widening add addc i32 %lhs, i32 %rhs, i1 %c -> i33 ; add with carry

Thanks Tom. I really appreciate your insight. I'm able to use the customize to get the 64-bit to go to a subroutine and for the 32-bit, I am generate XXXISD::MUL32. I'm not sure then what you mean about "overriding" the ReplaceNodeResults. For ReplaceNodeResults, I'm doing: SDValue Res = LowerOperation(SDValue(N, 0), DAG); for (unsigned I = 0, E =

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

At 2013-07-22 01:40:31,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/21/2013 09:49 AM, Star Tan wrote: >> Hi all, >> >> >> I have attached a patch file to reduce the polly-detect overhead. > >Great. > >> My idea is to avoid calling TypeFinder in Non-DEBUG mode, so >> TypeFinder is only called in DEBUG mode with the DEBUG