search for: storesdnode

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 getBasePtr...

...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 val...

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/aa...

...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 M...

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 handle...

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

...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/200703...

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

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

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 value...

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 a...

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

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

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

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

...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 M...

...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 LSBase...

...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 d...

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

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'll...