llvm dev - Nov 2007 - [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/aaee0354/attachment.html>

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 this.  One is to require that the targets 
custom expand the load/store to alternate address space at SDISel time. 
This way they could do any crazy thing they want, including lowering them 
into intrinsics, etc.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

On Nov 22, 2007, at 1:51 PM, Chris Lattner wrote:
> 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 this.  One is to require that the  
> targets
> custom expand the load/store to alternate address space at SDISel  
> time.
> This way they could do any crazy thing they want, including  
> lowering them
> into intrinsics, etc.
Forcing custom lowering for ISD::LOAD/STORE means that you lose lots  
of the information carried along with the Load/StoreSDNode that makes  
writing instruction patterns (particularly the ext/trunc predicates)  
simple.

Another possibility is to add a utility function to Load/StoreSDNodes  
that returns the address space of the pointer being used. For my use  
I think this way is probably best, though there's nothing preventing  
a target from doing custom lowering.

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20071125/a012cdbd/attachment.html>