search for: selectinst

.... and rebuild the binary using this profile clnag++ -o hmmer-fdo -fprofile-sample-use=hmmer.llvm \ -O3 -std=gnu89 -DSPEC_CPU -DNDEBUG -fno-strict-aliasing -w -g *.c now, sadly, this program runs in 231.2 seconds. The problem is that when a short conditional block is converted to a SelectInst, we are unable to accurately recover the branch frequencies since there is no actual branching. When we then compile in the presence of the sample, phase "CodeGen Prepare" examines the profile data and undoes the select conversion to disastrous results. If we compile -O0 for training, an...

On Fri, Aug 12, 2016 at 12:15 PM, Xinliang David Li via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +dehao. > > There are two potential problems: > > 1) the branch gets eliminated in the binary that is being profiled, so > there is no profile data > This seems like a fundamental problem for PGO. Maybe it is also responsible for this bug:

I have a question about the pattern matching stuff that's used in the Instruction Combiner. If I have code like this: if (match(B, m_Select(m_Value(), m_ConstantInt(0), m_ConstantInt(-1)))) { if (match(C, m_Not(m_Value(B)))) return SelectInst::Create(cast<User>(B)->getOperand(0), D, A); and we match, the program fails during the "SelectInst::Create" phase. The problem is because B is now a Constant with "-2" as its value, so it has 0 operands. It appears that the m_Not() match is changing the value of...

Hi all, Usually if we want to get the called Function we can directly use CallInst->getCalledFunction(), however, today i encounter an unusual CallInst as follows: %call11 = call double (...)* bitcast (double ()* @quantum_frand to double (...)*)() the original C source involve type cast: float u,v; extern double quantum_frand(); u = 2 * quantum_frand() - 1; v = 2 * quantum_frand() -

...e: > I have a question about the pattern matching stuff that's used in the > Instruction Combiner. If I have code like this: > > if (match(B, m_Select(m_Value(), m_ConstantInt(0), > m_ConstantInt(-1)))) { > if (match(C, m_Not(m_Value(B)))) > return SelectInst::Create(cast<User>(B)->getOperand(0), D, A); > > and we match, the program fails during the "SelectInst::Create" phase. > The problem is because B is now a Constant with "-2" as its value, so > it has 0 operands. It appears that the m_Not() match is cha...

...each i (`find . -name "*.cpp"`) ... end The other classes off the top of my head: setenv CLASS Function setenv CLASS SwitchInst setenv CLASS PHINode setenv CLASS BranchInst setenv CLASS CallInst setenv CLASS ReturnInst setenv CLASS InvokeInst setenv CLASS GetElementPtrInst setenv CLASS SelectInst setenv CLASS InsertElementInst There are some false substitutions that arise this way, but it mostly works. Be sure to recompile. Below I give an (marginally tested) monster script that should transform all these classes at once in your whole tree. Be sure to only use it on a tree without m...

...e uninteresting llvm ir branches, corresponding to the *if-else* condition in the source code. And here is the procedures: 1. Get the BasicBlock containing the BranchInst which has 2 successors(in order to keep consistent with the source code I am using the llvm ir without any optimizations, so SelectInst/SwitchInst/PHINode is absent), one of which should be pruned; let's name these 2 branches bb1 and bb2 and bb2 is to be pruned. 2. Find their nearest common post dominator, bb_join 3. Create a new branInst bb_new whose successors are bb1 and bb_join; replace the original BranchInst with bb...

...cognize a few idioms and synthesize horizontal > operations from 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 Fal...

...a32_blendvps">, Intrinsic<[llvm_v4f32_ty],[llvm_v4f32_ty, llvm_v4f32_ty, llvm_v4f32_ty],[IntrNoMem]> Thus, it expects the mask (first operand if i recall correctly) to be a <4 x float>. It would be great to have this mirrored in the IR, meaning one should be able to create a SelectInst with 3 <4 x float> operands which would generate this intrinsic. Is there anything that speaks against this? I think I also recall something similar for ICmp/FCmp instructions... Best, Ralf P.S. I am not up-to-date on the latest status of "direct" support of vector instructions...

...d a constant (for example, if the constant is a ConstantStruct), so be careful not to assume that a constant derivation maps to a single instruction. The case for ConstantExpr is probably the longest, but there aren't actually that many cases: you just have GetElementPtrInst, CastInst, CmpInst, SelectInst, InsertValueInst, and ExtractValueInst (assuming you wouldn't try to prove the legality for anything involving ptrtoint). (Okay, that list ended up a bit longer than I expected, but it still isn't that long.) -Eli

...etSuccessor(0);//BI is a conditional branch BasicBlock *FalseDest = BI->getSuccessor(1); BlockAddress * TrueDestAddr = BlockAddress::get(TrueDest); BlockAddress * FalseDestAddr = BlockAddress::get(FalseDest); Value * ConditionValue = BI->getCondition(); SelectInst * SI = SelectInst::Create(ConditionValue, TrueDestAddr, FalseDestAddr, "", BI); IndirectBrInst *indirBr = IndirectBrInst::Create(SI, 2, BI); indirBr->addDestination(TrueDest); indirBr->addDestination(FalseDest); BI->eraseFromParent(); But I met the...

Hi, I would like to transform unpredictable conditional branches with a small body into cmov instructions to reduce branch miss penalty. LLVM generates cmov/setcc instructions when SelectInst is used. The idea is to transform regular branches into selects, when that is possible and profitable. However this needs branch prediction info, and it seems LLVM doesn't provide that AFAICT. Could gcc's branch predictor be used here, or are there plans for an llvm-specific branch predict...

In the section about poison values, the LLVM language reference manual says: "Values other than phi nodes depend on their operands." This implies that a select instruction's output can be poisoned by its not-selected argument value. If select were poisoned only by its selected argument, we would expect this fact to be mentioned specifically, as it is for phi. Next I'll

Hi, I've been struggling with constantexprs for a bit. I'm working on a pass that transforms global variables to local variables, and in particular the GetElementPtrConstantExpr is a bit troublesome. For my transformation to properly work, a global value should only be used by Instructions, not by ConstantExprs. I was thinking to add a ConstantExpr::replaceWithInstr() virtual method,

...Block *FalseDest = BI->getSuccessor(1); > > > > BlockAddress * TrueDestAddr = BlockAddress::get(TrueDest); > > BlockAddress * FalseDestAddr = BlockAddress::get(FalseDest); > > > Value * ConditionValue = BI->getCondition(); > > > > SelectInst * SI = SelectInst::Create(ConditionValue, TrueDestAddr, > FalseDestAddr, "", BI); > > > > IndirectBrInst *indirBr = IndirectBrInst::Create(SI, 2, BI); > > indirBr->addDestination(TrueDest); > > indirBr->addDestination(FalseDest); > &gt...

After I implemented a new type of legalization (the packing of i1 vectors), I found that x86 does not have a way to load packed masks into SSE registers. So, I guess that legalizing of <4 x i1> to <4 x i32> is the way to go. Cheers, Nadav -----Original Message----- From: Rotem, Nadav Sent: Thursday, March 10, 2011 11:04 To: 'David A. Greene' Cc: llvmdev at cs.uiuc.edu

On Mar 29, 2008, at 6:02 AM, Török Edwin wrote: > Hi, > > I would like to transform unpredictable conditional branches with a > small body into cmov instructions to reduce branch miss penalty. > LLVM generates cmov/setcc instructions when SelectInst is used. The > idea > is to transform regular branches into selects, when that is possible > and > profitable. LLVM is already aggressively turning branches into selects as far as I can see. > > However this needs branch prediction info, and it seems LLVM doesn't >...

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

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

> let me say that in general doing this is pointless. Due to SSA form, if %x is > set to 5 you can't set it to something else later. Thus everywhere that > you > use %x you might as well just directly use 5 there instead. My bad... I should've started thinking in SSA way all the time. I got it mixed with common assembly language. So I must hold the initial value until the