search for: storesdnod

Displaying 20 results from an estimated 43 matches for "storesdnod".

Did you mean: storesdnode
2008 Sep 18
2
[LLVMdev] store addrspace qualifier
Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the getBasePt...
2007 Nov 25
1
[LLVMdev] Getting the pointer type from a Load/Store SDNode
...wrote: >> I'm digging into this, but I'd like to know if it's feasible to >> get to the >> pointer type from a Load/Store SDNode? This would relieve me from >> having to >> put the address space information into those SDNodes. >> >> Is Load/StoreSDNode->getSrcValue()->getType() going to do what I >> want? >> If not, I can't see another way of getting to the pointer type. > > Hrm, the codegen has a couple of interesting crazy issues. For > example, > it thinks there is a current PointerTy() that is always va...
2007 Nov 22
2
[LLVMdev] Getting the pointer type from a Load/Store SDNode
I'm digging into this, but I'd like to know if it's feasible to get to the pointer type from a Load/Store SDNode? This would relieve me from having to put the address space information into those SDNodes. Is Load/StoreSDNode->getSrcValue()->getType() going to do what I want? If not, I can't see another way of getting to the pointer type. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071121/a...
2013 Feb 19
9
[LLVMdev] [RFC] Add Intel TSX HLE Support
...mbedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode here is the current SDNode class hierarchy of memory related nodes SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode | + -> StoreSDNode + -> AtomicSDNode + -> MemIntrinsicSDNode here is the current SubclassData definitions: bit 0~1 : extension type used in LoadSDNode bit 0 : truncating store in StoreSDNode bit 2~4 : addressing mode in LSBaseNode bit 5 : volatile bit in...
2007 Nov 22
0
[LLVMdev] Getting the pointer type from a Load/Store SDNode
On Wed, 21 Nov 2007, Christopher Lamb wrote: > I'm digging into this, but I'd like to know if it's feasible to get to the > pointer type from a Load/Store SDNode? This would relieve me from having to > put the address space information into those SDNodes. > > Is Load/StoreSDNode->getSrcValue()->getType() going to do what I want? > If not, I can't see another way of getting to the pointer type. Hrm, the codegen has a couple of interesting crazy issues. For example, it thinks there is a current PointerTy() that is always valid. I see a couple ways to handl...
2007 Jan 06
1
[LLVMdev] Custom load/store code: determining offset or alignment
...alignment as a predicate in the tblgen files? If so, this would likely take care of the normal case if the POD is on the stack and writing patterns is a lot easier than custom selecting or lowering. Q2: Is there any way to determine a POD's offset based on a LoadSDNode and StoreSDNode's data? Currently, LoadSDNode::getBasePtr (and StoreSDNode::getBasePtr) can return something back, but how do I access the operand's offset (and hence, alignment) relative to a base register? Q3: There are three variants of load (and store) for the SPU. Two of the variants...
2007 Mar 10
2
[LLVMdev] LLVM with Microsoft Visual Studio
...where I am now but if anyone can take it for a spin to test it and verify the fix then by all means check it in. I'm just providing a hand-edited diff from our vendor branch here (1.9 tarball version); it's the best I can do right now. I think the most important part was the change to the StoreSDNode constructor which relied on implicit type lookup. // Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-msvc2005.patch.gz Type: application/x-gzip Size: 1904 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070...
2008 Sep 17
0
[LLVMdev] store addrspace qualifier
The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier
2010 Feb 10
2
[LLVMdev] Metadata
...them? > > Is there any reason we would not want to support metadata on SDNodes, > other than the cost of implementing it? We don't necessarily need to do that > now. I'm just asking the question with future possibilities in mind. I think that adding a bit to LoadSDNode and StoreSDNode would make sense. -Chris
2007 Mar 10
0
[LLVMdev] LLVM with Microsoft Visual Studio
No, the problem with StoreSDNode was that an argument as being called Value, which hid the class Value later on in the argument list. This also broke 2003 and was fixed a while ago. _WIN32_WINNT is not supposed to be predefined, so that warning shouldn't be occurring. I have never seen it myself, and a predefined valu...
2010 Feb 10
3
[LLVMdev] Metadata
On Feb 10, 2010, at 12:42 PM, David Greene wrote: > On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote: > >> I think that adding a bit to LoadSDNode and StoreSDNode would make sense. > > Ok. The consequence is that a number of functions will have to change to > propagate this bit, analogous to what happens with isVolatile. It's > essentially what we do right now here. If everyone's ok with that, I'll go > that route. Putting...
2008 Sep 17
2
[LLVMdev] store addrspace qualifier
How do I access the address qualifier from the store instruction. Given the following code: define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) nounwind { entry: %neg = sub float -0.000000e+000, %x ; <float> [#uses=1] store float %neg, float addrspace(11)* %result ret void } When I attempt to generate this code, I'm
2013 Feb 19
0
[LLVMdev] [RFC] Add Intel TSX HLE Support
...s. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode > | + -> StoreSDNode > + -> AtomicSDNode > + -> MemIntrinsicSDNode > > here is the current SubclassData definitions: > > bit 0~1 : extension type used in LoadSDNode > bit 0 : truncating store in StoreSDNode > bit 2~4 : addressing mode in...
2013 Feb 19
0
[LLVMdev] [RFC] Add Intel TSX HLE Support
...s. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode > | + -> StoreSDNode > + -> AtomicSDNode > + -> MemIntrinsicSDNode > > here is the current SubclassData definitions: > > bit 0~1 : extension type used in LoadSDNode > bit 0 : truncating store in StoreSDNode > bit 2~4 : addressing mode in...
2013 Feb 19
0
[LLVMdev] [RFC] Add Intel TSX HLE Support
...s. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode > | + -> StoreSDNode > + -> AtomicSDNode > + -> MemIntrinsicSDNode > > here is the current SubclassData definitions: > > bit 0~1 : extension type used in LoadSDNode > bit 0 : truncating store in StoreSDNode > bit 2~4 : addressing mode in...
2013 Feb 19
2
[LLVMdev] [RFC] Add Intel TSX HLE Support
...mbedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode here is the current SDNode class hierarchy of memory related nodes SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode | + -> StoreSDNode + -> AtomicSDNode + -> MemIntrinsicSDNode here is the current SubclassData definitions: bit 0~1 : extension type used in LoadSDNode bit 0 : truncating store in StoreSDNode bit 2~4 : addressing mode in LSBaseNode bit 5 : volatile bit in...
2013 Feb 19
0
[LLVMdev] [RFC] Add Intel TSX HLE Support
...assData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode > | + -> StoreSDNode > + -> AtomicSDNode > + -> MemIntrinsicSDNode > > here is the current SubclassData definitions: > > bit 0~1 : extension type used in LoadSDNode > bit 0 : truncating store in StoreSDNode > bit 2~4 : addressing mode in LSBas...
2006 Dec 14
3
[LLVMdev] ThisCall / Compilation problems
...les etc, but would like to contribute to the project). Also, I'm using MS Visual C++ Express, and there are a few things that stop llvm1.9 (and the current CVS release) from compiling correctly - once again, not sure how to submit, but here are the main things - In SelectionDAGNodes.h StoreSDNode(SDOperand Chain, SDOperand Value, SDOperand Ptr, SDOperand Off, ISD::MemOpAddrMode AM, bool isTrunc, MVT::ValueType SVT, const Value *SV, int O=0, unsigned Align=0, bool Vol=false) SDOperand Value should really be SDOperand value (lower case), since Value is already a...
2010 Feb 10
0
[LLVMdev] Metadata
On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote: > I think that adding a bit to LoadSDNode and StoreSDNode would make sense. Ok. The consequence is that a number of functions will have to change to propagate this bit, analogous to what happens with isVolatile. It's essentially what we do right now here. If everyone's ok with that, I'll go that route....
2010 Feb 11
0
[LLVMdev] Metadata
On Wednesday 10 February 2010 14:58:58 Dan Gohman wrote: > On Feb 10, 2010, at 12:42 PM, David Greene wrote: > > On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote: > >> I think that adding a bit to LoadSDNode and StoreSDNode would make > >> sense. > > > > Ok. The consequence is that a number of functions will have to change to > > propagate this bit, analogous to what happens with isVolatile. It's > > essentially what we do right now here. If everyone's ok with that, I'l...