similar to: [LLVMdev] How to do bitcast for double to <2 x double>

So, you need to bitcast `pinst` to a pointer to Vector of double, since it (I hope for your sake) is a pointer to integer. What you are trying to do is bitcast a pointer into a vector, which probably will lead to an assert or "bad code that doesn't work". -- Mats On 15 April 2015 at 21:57, zhi chen <zchenhn at gmail.com> wrote: > What I want to do is to change the pInst

Does anyone know how to instrument *double* to <2 x doulbe>**, e.g., 2.2 --> <2.2, 2.2>? For example, I want to change the following IR code %arrayidx1 = getelementptr inbounds [100 x double]* @main.B, i32 0, i32 %i.021 %1 = load double* %arrayidx1, align 4, !tbaa !0 to: %arrayidx1 = getelementptr inbounds [100 x double]* @main.B, i32 0, i32 %i.021 %1 = bitcast double* %arrayidx1

It seems that the problem was because I used builder.CreateFAdd to create a <2 x double> vectortype FADD instruction. It works if I use it to create the scalar version FADD. I want to have an instruction like: *%2 = fadd <2 x double> undef, <2 x double> undef. *The following is the way I used to create the vectorized FADD instruction: //pInst is a double type instruction

I got it. Thanks, Nick. So, it is back to the previous problem. If I have the following instruction: %3 = fadd double %1, double %2 I want to change it into %6 = fadd <2 x double> %4, double %5 where %4 = <double %1, double %1>, %5 = <double %2, double %2>, how can I do this? Thanks, Best On Fri, Apr 17, 2015 at 1:56 AM, Nick Lewycky <nicholas at mxc.ca> wrote: >

Does the insert point also mean inserting before the instruction? On Tue, Apr 21, 2015 at 3:36 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > IRBuilder takes an insertion point. > Use it? > > > On Tue, Apr 21, 2015 at 3:17 PM, zhi chen <zchenhn at gmail.com> wrote: > > The current instruction is: > > > > Instruction *pInst; > > > >

Thanks Nick, that's something what I am trying to implement as the following. But it seems I still only get the constant value not the instruction. Could you please go over the following instruction and see what wrong with it? Thanks for your time again. Value *vecVal = NULL; IRBuilder<> builder(&*pInst); Type *vecTy = VectorType::get(Type::getDoubleTy(ctxt), 2); Value

The current instruction is: Instruction *pInst; How can I create a new instruction, say add, after pInst? Thanks, Zhi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150421/8f75a4a0/attachment.html>

Value * is the instruction. use dyn_cast<Instruction> to get to it. On Thu, Apr 16, 2015 at 11:39 PM zhi chen <zchenhn at gmail.com> wrote: > But IRBuilder.CreateXYZ only returns a "VALUE" type. Can I get the > instruction created by it? For example, > > IRBuilder<> builder(&*pinst); > Value *val = builder.CreateFAdd(LV, RV, ""); >

Yes. That's what I was the solution in my mind. But I just wanted to know if there was a generic way to save some code... On Thu, Apr 16, 2015 at 8:32 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > I understand that I can detect the operation first, and use "create" to > > create for each of them. But I don't if there is a generic way to do this

I read the tutorial document, but I didn't understand the it and Ops fields of instruction class well. Can any one give me an example? Instruction *newInstr = new Instruction(Type *ty, unsigned it, Use *Ops, unsigned NumOps, Instruction *InsertBefore); For example, I have an *instruction *pInst *without no the type of operation in advance. If I want to create a new instruction which is

> On Mar 15, 2016, at 4:09 PM, Philip Reames <listmail at philipreames.com> wrote: > > > > On 03/15/2016 03:07 PM, via llvm-dev wrote: >> There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to

Hi, I'm quite puzzled by a little bit of code in the DAGCombiner where it merges loads in MergeConsecutiveStores. Two 16bit loads have been merged to one 32bit load, and two 16bit stores have been combined to one 32bit store. And then the code goes like this: // Replace one of the loads with the new load. LoadSDNode *Ld = cast<LoadSDNode>(LoadNodes[0].MemNode);

Hi, I am writing an llvm target and I need both loads for isel reasons, but I am struggling to find the right way. I have been trying to use DAG.getLoad() to make a copy, then just change the operand in the consumers, but I cannot seem to get all of the arguments needed for that function in order to make the copy. Any help would be great, thanks! -Joe -------------- next part -------------- An

Hi, Joseph, I guess getLoad() will either search an existed SDValue *OR* create a new one for a non-existed one depending on real parameters. Since you use exactly the same attributes dupVal/dupNode have, no doubt getLoad() return the old one. I am not sure it's *volatile* that let you get a new result, you might want to try change some other parameters and check what it turns out. Regards.

So I think I have made some progress. SDValue dupVal = consumer->getOperand(OpNo); LoadSDNode *dupNode = (LoadSDNode*) dupVal.getNode(); SDValue newLoad = CurDAG->getLoad(dupVal.getValueType(), dupVal.getDebugLoc(), dupVal.getOperand(0), dupVal.getOperand(1), dupNode->getPointerInfo(),

Hi, Joe. I am sorry I did not catch your point. Can you provide more details? Since SDValue/SDNode can be used multiple times, why would you want to create two identical objects instead of reference to the same one? 2012/12/2 Joseph Pusdesris <joe at pusdesris.com>: > Yes, changing parameters will create a new Node, but is there some way I can > force a new node with the same

Yes, changing parameters will create a new Node, but is there some way I can force a new node with the same parameters? -Joe On Sat, Dec 1, 2012 at 10:57 PM, Triple Yang <triple.yang at gmail.com> wrote: > Hi, Joseph, I guess getLoad() will either search an existed SDValue > *OR* create a new one for a non-existed one depending on real > parameters. > > Since you use

OK, I get it. The essence of this problem is that a node can be covered exactly and just once but its result can be referred multiple times for a tree pattern matching isel. So to duplicate a load node (only if we can!) is convenient to conquer that case. The truth is, in pattern (add (load) (load)), source operands are memory addresses, and thus it can be treated as (addmm address,

There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to some degree as well (there might be others?). To put it simply: at least in my profile, EarlyCSE spends ~1/5 of its time growing DenseMaps. This is kind of… bad.

I am writing a target for an odd cisc-like architecture which has no support for keeping most values in registers. As such, memory-memory operations are needed, but for isel to generate a memory-memory the pattern must be of the form (store (op (load) (load))). Let's use a simple example to show how this can be problematic: %0 = load i32* %a.addr, align 4 store i32 %0, i32* %other, align