similar to: [LLVMdev] Splitting a load with 2 consumers into 2 loads.

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.

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

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(),

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,

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

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

I'll give that a shot, thanks! -Joe On Sun, Dec 2, 2012 at 12:06 PM, Triple Yang <triple.yang at gmail.com> wrote: > 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

Sorry, forgot to Reply-All. Begin forwarded message: > From: Steve Montgomery <stephen.montgomery3 at btinternet.com> > Subject: Re: [LLVMdev] Prevention register promotion at the isel codegen phase > Date: 24 November 2012 17:09:58 GMT > To: Joseph Pusdesris <joe at pusdesris.com> > > I had a similar problem trying to implement reg-mem operations. The solution I

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);

Yes, this is very helpful! Thank you! How does this work when exiting a variable's liveness range? Will it automatically know to free the stack slot for reuse? -Joe On Sat, Nov 24, 2012 at 12:23 PM, Steve Montgomery < stephen.montgomery3 at btinternet.com> wrote: > Sorry, forgot to Reply-All. > > Begin forwarded message: > > *From: *Steve Montgomery

Hi, For my research, I need to reshape the current ARM backend to support armv2a. Zero-extend half word load (ldrh) is not supported by armv2a, so I need to make the code generation to not generate ldrh instructions. I want to replace all those instances with a 32-bit load (ldr) and then and the result with 0xffff to mask out the upper bits. These are the modifications that I have made to

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: >

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

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, ""); >

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

How can I write code to generate IR for: %2 = bitcast double* %1 to <2 x double>*. %3 = load <2 x double>* %2, align 16 Basically, it is similar to x86 _mm_load_pd1 intrinsics. Thanks, Zhi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150415/66489860/attachment.html>

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized

While hacking around in the SelectionDAG build code, I've made the isVolatile, (new) isNonTemporal and Alignment parameters to SelectionDAG::getLoad/getStore and friends non-default. I've already caught one bug in the XCore backend by doing this: if (Offset % 4 == 0) { // We've managed to infer better alignment information than the load // already has. Use an aligned

On Tue, Dec 19, 2006 at 01:31:10PM -0800, Evan Cheng wrote: > > On Dec 19, 2006, at 12:13 PM, Dan Gohman wrote: > > > Hello, > > > > I did a little experiment modifying LLVM to be able to use alias- > > analysis > > information in scheduling so that independent memory operations may be > > reordered. > > I am not sure if it is a good idea to