search for: createselect

...lue *in1, llvm::Value *in2) { std::vector<llvm::Value*> vec1 = extractVector(in1); // generate LLVM extract element std::vector<llvm::Value*> vec2 = extractVector(in2); Value *xcmp = m_builder.CreateFCmpOLT(vec1[0], vec2[0], name("xcmp")); Value *selx = m_builder.CreateSelect(xcmp, vec1[0], vec2[0], name("selx")); Value *ycmp = m_builder.CreateFCmpOLT(vec1[1], vec2[1], name("ycmp")); Value *sely = m_builder.CreateSelect(ycmp, vec1[1], vec2[1], name("sely&quot...

...> std::vector<llvm::Value*> vec1 = extractVector(in1); // generate LLVM > extract element > std::vector<llvm::Value*> vec2 = extractVector(in2); > > Value *xcmp = m_builder.CreateFCmpOLT(vec1[0], vec2[0], name("xcmp")); > Value *selx = m_builder.CreateSelect(xcmp, vec1[0], vec2[0], > name("selx")); > > Value *ycmp = m_builder.CreateFCmpOLT(vec1[1], vec2[1], name("ycmp")); > Value *sely = m_builder.CreateSelect(ycmp, vec1[1], vec2[1], >...

..."sqrt", B, Callee->getAttributes()); Value *FAbs = EmitUnaryFloatFnCall(Sqrt, "fabs", B, Callee->getAttributes()); Value *FCmp = B.CreateFCmpOEQ(Op1, NegInf); Value *Sel = B.CreateSelect(FCmp, Inf, FAbs); return Sel; } [...] } So, before the callOptimizer call, it actually does check TLI to see that powf is available. However, the code below (that expands pow(x, 0.5) ) emits sqrt and fabs without making any checks. This may be problematic in two cases: 1) If LibF...

...Callee->getAttributes());**** > > Value *FAbs = EmitUnaryFloatFnCall(Sqrt, "fabs", B,**** > > Callee->getAttributes());**** > > Value *FCmp = B.CreateFCmpOEQ(Op1, NegInf);**** > > Value *Sel = B.CreateSelect(FCmp, Inf, FAbs);**** > > return Sel;**** > > }**** > > ** ** > > [...]**** > > }**** > > ** ** > > So, before the callOptimizer call, it actually does check TLI to see that > powf is available. However, the code below (that expands pow(x, 0.5)...

...rom them, but I think only addition is currently recognized, and Thanks Duncan, you're right - that does compile to a mess of spills to memory not unlike the original. I went to have a look at this further: It seems the existing SelectInst is pretty close to what is needed. Value IRBuilder::*CreateSelect(Value *C, Value *True, Value *False, const Twine &Name) Currently, this asserts that the True & False are both vector types of the same size as "C". I was thinking of weakening this condition so that if True and False are both i1 types, it will be allowed and will result in someth...

...ter/llvm/lib/CodeGen/CodeGenPrepare.cpp#L6065 Alexey On Thu, Jan 30, 2020 at 9:00 PM John Regehr via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Several different passes introduce select instructions, such as > InstCombine, SimplifyCFG, and SROA. Searching for calls to > "CreateSelect" in the source tree should give you a fairly complete list. > > It may be better to let the optimization pipeline proceed undisturbed, > but then run a custom pass at the end that turns selects back into > control flow. This would be an easy pass to write. > > John > >...

Hi, I would like to know if there's a way to avoid select instructions during the IR generation. What are the optimization passes that can result in a select instruction? i.e. I want to preserve branches in my code without disabling any other optimizations applicable. For example, void foo(int* x, int* y){ if(*x > 0){ *y = *x + 10; } else{ *y = *x + 20; } }

...> = > = > =-------------------------------------------------------------------- > ===// > + // Instruction creation methods: Other Instructions > + // > = > = > =-------------------------------------------------------------------- > ===// > + > + Value *CreateSelect(Value *C, Value *True, Value *False, > + const char *Name = "") { > + if (Constant *CC = dyn_cast<Constant>(C)) > + if (Constant *TC = dyn_cast<Constant>(True)) > + if (Constant *FC = dyn_cast<Constant>(False)) > +...

Devang Patel wrote: > On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > >> I got the current version of LLVM via svn yesterday and modified my >> code to >> use the LLVMFoldingBuilder. Very nice! >> >> My question is this: I noticed that the folding builder doesn't fold >> some >> operations, e.g. casts. Is there some reason why? If

Hi Stephen, > Hi all, llvm newbie here. welcome! > I'm trying to branch based on a vector compare. I've found a slow way (below) > which goes through memory. Is there some idiom I'm missing so that it would use > for instance movmsk for SSE or vcmpgt & cr6 for altivec? I don't think you are missing anything: LLVM IR has no support for horizontal operations like

Hi all, llvm newbie here. I'm trying to branch based on a vector compare. I've found a slow way (below) which goes through memory. Is there some idiom I'm missing so that it would use for instance movmsk for SSE or vcmpgt & cr6 for altivec? Or do I need to resort to calling the intrinsic directly? Thanks, Stephen. %16 = fcmp ogt <4 x float> %15, %cr %17 =

...tly recognized, and > > Thanks Duncan, > > you're right - that does compile to a mess of spills to memory not > unlike the original. > > I went to have a look at this further: It seems the existing SelectInst > is pretty close to what is needed. > Value IRBuilder::*CreateSelect(Value *C, Value *True, Value *False, > const Twine &Name) > Currently, this asserts that the True & False are both vector types of > the same size as "C". I was thinking of weakening this condition so that > if True and False are both i1 types, it will be allowed and w...