search for: srcvalu

hi, i am building selectionDAG by my own code, but got a assertion fail said "SrcValue is not a pointer?". but since the comment above the SrcValueSDNode said: "SrcValueSDNode - An SDNode that holds an arbitrary LLVM IR Value." why the llvm value of SrcValueSDNode must be with PointerType? is that assertion necessary? thanks a lots. regards --ether

...use the Value class is a parent class to many many child classes. --Sam ----- Original Message ---- > From: ether zhhb <etherzhhb at gmail.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thu, December 3, 2009 7:45:42 PM > Subject: [LLVMdev] "SrcValue is not a pointer?" assertion in SelectionDAG::getSrcValue > > hi, > > i am building selectionDAG by my own code, but got a assertion fail > said "SrcValue is not a pointer?". > > but since the comment above the SrcValueSDNode said: "SrcValueSDNode - >...

...e modified the loadRegFromStackSlot and storeRegToStackSlot methods to add information on the frame index: BuildMI(MB, MBI, TII.get(STORE_REG_IMM)).addReg(framePointer) .addFrameIndex(FrameIndex).addReg(SrcReg).addSVOp(FrameIndex); > I'm curious why you added a new node kind, TargetSrcValue, instead of just > using the existing SRCVALUE. this is needed to ensure that the lowering pass does not rewrite them. i don't know if this is actually done, but anyway i wanted to be on the safe side. > >> + else if (MRO.SrcValue && !MRO.SrcValue->getName().empty(...

...1026 SV:0 RET SV:0 (For those following along, the SV:1[??] and SV:1[q] are the new parts here). For the [??], it looks like the IsFrameIndex isn't getting set for the first instruction there. A few quick comments on specific parts of the patch that I noticed so far: > + TargetSrcValue, I'm curious why you added a new node kind, TargetSrcValue, instead of just using the existing SRCVALUE. > + else if (MRO.SrcValue && !MRO.SrcValue->getName().empty()) > + OS << "[" << MRO.SrcValue->getName() << "]"; This cod...

hi, i know it took a while, but here is a patch that adds a list of source values to machine instructions. i modified the DAGISelEmiter to automatically catch regular loads/stores. custom instructions and loads/stores rewritten by the lowering pass are not automatically captured. during the instruction selection a source value operand is added to the DAG for patterns matching a load/store.

...x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added another flag to the MemSDNode constructor and embedded it in SubclassData: MemSDNode(unsigned Opc, DebugLoc dl, SDVTList VTs, MVT MemoryVT, const Value *srcValue, int SVOff, unsigned alignment, bool isvolatile, bool NonTemporal); This is ugly for a variety of reasons and also doesn't scale as we want to add more of this kind of information. So what if we replace Volatile/NonTemporal with a single bitvector? There's not a lot of room i...

...gn 8 %3 = load %ravi.LClosure** %2, align 8 %Proto = getelementptr inbounds %ravi.LClosure* %3, i64 0, i32 5 %4 = load %ravi.Proto** %Proto, align 8 %k = getelementptr inbounds %ravi.Proto* %4, i64 0, i32 14 %5 = load %ravi.TValue** %k, align 8 %6 = load %ravi.TValue** %base, align 8 %srcvalue = getelementptr inbounds %ravi.TValue* %5, i64 0, i32 0, i32 0 %destvalue = getelementptr inbounds %ravi.TValue* %6, i64 0, i32 0, i32 0 %7 = load double* %srcvalue, align 8 store double %7, double* %destvalue, align 8 %srctype = getelementptr inbounds %ravi.TValue* %5, i64 0, i32 1 %des...

new warnings, I think lib/CodeGen/SelectionDAG/DAGCombiner.cpp: In member function ‘llvm::SDValue<unnamed>::DAGCombiner::FindBetterChain(llvm::SDNode*, llvm::SDValue)’: lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6006: warning: ‘SrcValueOffset’ may be used uninitialized in this function lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6006: note: ‘SrcValueOffset’ was declared here lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6005: warning: ‘SrcValue’ may be used uninitialized in this function lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6005:...

Hi, > My initial reaction is that if one were to decorate MachineInstr's > with the LLVM level pointer values that they use for reading > and writing memory, this is already the case: SrcValue and SVOffset. Ciao, Duncan.

...low. As you can see the loads are still present. ; ModuleID = 'ravi_module_ravif1' target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-windows-msvc-elf" %0 = type { %ravi.TValue*, i32*, i64 } .... %6 = load %ravi.TValue** %base %srcvalue = getelementptr inbounds %ravi.TValue* %5, i32 0, i32 0, i32 0 %destvalue = getelementptr inbounds %ravi.TValue* %6, i32 0, i32 0, i32 0 %7 = load double* %srcvalue store double %7, double* %destvalue %srctype = getelementptr inbounds %ravi.TValue* %5, i32 0, i32 1 %desttype = getelement...

hi, Florian Brandner wrote: > Dan Gohman wrote: >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: >>> Right. The original Value*'s are preserved in the DAG, but dropped when >>> MachineInstrs are created. We could add a machineoperand to capture this >>> Value* if desired. >> Another benefit of keeping the original Value*'s

...n (we'll also add the TableGen patterns to properly select > movnt). > > In our tree we simply added another flag to the MemSDNode constructor > and embedded it in SubclassData: > > MemSDNode(unsigned Opc, DebugLoc dl, SDVTList VTs, MVT MemoryVT, > const Value *srcValue, int SVOff, > unsigned alignment, bool isvolatile, bool NonTemporal); > > This is ugly for a variety of reasons and also doesn't scale as we > want to add more of this kind of information. > > So what if we replace Volatile/NonTemporal with a single bitvector? >...

...n (we'll also add the TableGen patterns to properly select > movnt). > > In our tree we simply added another flag to the MemSDNode constructor > and embedded it in SubclassData: > > MemSDNode(unsigned Opc, DebugLoc dl, SDVTList VTs, MVT MemoryVT, > const Value *srcValue, int SVOff, > unsigned alignment, bool isvolatile, bool NonTemporal); > > This is ugly for a variety of reasons and also doesn't scale as we > want to add more of this kind of information. > > So what if we replace Volatile/NonTemporal with a single bitvector? >...

I am pretty excited about the recent activity on dependence analysis. The only remaining problem from our point of view is how to get the alias information to the back end instruction scheduler. If I understand things correctly, the alias information basically gets lost in the process of lowering to target instructions. We are interested in the DSP domain, so we really need to get SIMD style

On 22 February 2015 at 20:58, David Jones <djones at xtreme-eda.com> wrote: > Not sure if this is your problem, but it was mine: > > You must create (or obtain) a DataLayout *and install it into the Module*. > > It is possible to generate machine code for IR and not install the > DataLayout into the Module. Rather, the DataLayout is used locally at the > point where code

On 23 February 2015 at 01:29, Kamal Sharma <kgs1.rice at gmail.com> wrote: > Hi Dibyendu, > > It would be very helpful if you could post the original source code or > snippet. > That way, one can investigate deeper to understand the problem. > > Regards, > Kamal Sharma > Hi Kamal, Sure. I guess I ought to create a test that one can look in isolation. I am

...antPoolSDNode>(Base) || + isa<GlobalAddressSDNode>(Base); + } + + /* FIXME: copied from DAGCombiner.cpp */ + /// isAlias - Return true if there is any possibility that the two addresses + /// overlap. + bool isAlias(SDOperand Ptr1, int64_t Size1, + const Value *SrcValue1, int SrcValueOffset1, + SDOperand Ptr2, int64_t Size2, + const Value *SrcValue2, int SrcValueOffset2) + { + // If they are the same then they must be aliases. + if (Ptr1 == Ptr2) return true; + + // Gather base node and offset information. + SDOperand Ba...

...> HANDLENODE, > > - // TRAMPOLINE - This corresponds to the init_trampoline intrinsic. > - // It takes as input a token chain, the pointer to the trampoline, > - // the pointer to the nested function, the pointer to pass for the > - // 'nest' parameter, a SRCVALUE for the trampoline and another for > - // the nested function (allowing targets to access the original > - // Function*). It produces the result of the intrinsic and a token > - // chain as output. > - TRAMPOLINE, > + // INIT_TRAMPOLINE - This corresponds to the init...

...07ffff6b5d179 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () from /opt/buildbot/lib/libOpenCL.so.1 > #21 0x00007ffff6b1282c in (anonymous namespace)::compile_llvm (llvm_ctx=..., > source="\n__kernel void test_fn(__local float *sSharedStorage, __global float *srcValues, __global uint *offsets, __global float *destBuffer, uint alignmentOffset )\n{\n int tid = get_global_id( 0 );\n sSha"..., headers=..., name="input.cl", triple="r600--", processor="verde", opts="", > address_spaces=..., optimization_level=...

Hi! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc: