search for: getloader

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.

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

Hello, I'm trying to understand SelectionDAG::getLoad() and the relation between the pointer and MachineMemOp. What does the MachineMemOp do in the getLoad()? Why is both pointer (parameters SDValue Ptr, SDValue Offset) and the MMO (parameters const Value *SV, int SVOffset) needed? And the Alignment parameter seems to be the alignment of the SV without the Offset, aswell as the generated LOAD

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

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

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

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

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,

On Thursday 11 February 2010 17:40:24 David Greene wrote: > 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

On Fri, September 12, 2008 11:33 am, Stefanus Du Toit wrote: > Hi, > > We've noticed that constant loads, e.g. of v4f32 types, are not > aligned to the preferred alignment but rather to the ABI alignment, at > least on x86. On x86 targets it's usually 16 for both preferred and ABI. I guess you're using a target with a lower ABI alignment for vectors? > This seems to

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

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 do this at scheduling time. LLVM explicitly models control flows dependencies as chain operands. This eliminated

Hi Dan, > It looks like the best way to do this is to visit the handful of > places in legalize that create loads from constant pools and > add alignment parameters to the getLoad/getExtLoad calls. > > If you move the handling of Alignment==0 out of ScheduleDAGEmit.cpp > and into SelectionDAG::getConstantPool, you can then have legalize > read the alignment from the node,

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

> so I think we need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. > if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { > return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); > } else { > return

I am having trouble adding a node to the selection DAG (e.g. during combine) E.g. node1 -> use1, use2 Now if you add a node2, with node1 -> node2 with node2 number of output values equal node1 number of output values, then combine as well as e.g. promotion pass with replace all of node1's uses with node2, leaving node1 dead. While this is kind of expected, does this mean a) always

On Fri, Feb 12, 2010 at 1:43 PM, David Greene <dag at cray.com> wrote: > On Thursday 11 February 2010 17:40:24 David Greene wrote: >> 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

In ARM, constants that are too large to be used as immediate are usually placed in a constant pool and loaded. What I am trying to do is to have a select function that checks the if a constant can be an immediate and, if it can't, produces a load: --------------------------------------------------------------------------------------- const Type *OpNTy =