llvm dev - Nov 2007 - [LLVMdev] C embedded extensions and LLVM

On Nov 12, 2007, at 10:57 PM, Chris Lattner wrote:
> On Nov 11, 2007, at 11:18 AM, Christopher Lamb wrote:
>>> Any property that affects how the value is stored in registers
>>> needs to be in the type instead of on the load/store instruction.
>>> Also, unlike volatile, it is not common to cast a pointer between
>>> two different address spaces.
>>
>> Though perhaps infrequent, casting between address spaces is allowed
>> based on rules that the target defines indicating which address
>> spaces are subsets of others.
>
> Right.
>
>> Does supporting those casts require an explicit operation (ie
>> intrinsic)?
>
> This should just be a bitcast from one pointer to another pointer  
> type.
Good.
>>> The meat of project boils down to adding a new address space
>>> qualifier field to PointerType, making sure PointerType takes this
>>> field into account when it is being uniqued, and adding the address
>>> space qualifier to things like global variable.
>>>
>>> Does this sound reasonable?
>>
>> That sounds like it should be easier than adding the address space
>> ID to all the instructions and SDNodes.
>>
>> I'll give it a try and see what happens. I can see that adding it
to
>> the type system makes it easier on the optimizer, but I don't yet
>> understand all the consequences for the code generator.
>
> I don't know what the right answer is for codegen either.  I'd
suggest
> getting the llvm ir self-consistent, then worrying about it.  Until we
> have a concrete machine that needs it, it is hard to anticipate what
> will be needed.
Indeed.
> In an ideal world, we'll just need flags on load/
> store nodes because the pointer registers will already be lowered to
> some other regclass.
I assume malloc's and memcpy's would need them as well?

--
Christopher Lamb



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

>> In an ideal world, we'll just need flags on load/
>> store nodes because the pointer registers will already be lowered to
>> some other regclass.
>
> I assume malloc's and memcpy's would need them as well?
Yeah, seems likely.  I think malloc gets lowered in SDISel to a call  
though, so maybe it doesn't need it.  I'm not sure what "malloc
from
alternate address space" really means though.  There can only be one  
function named "malloc" :).  Maybe LangRef should explicitly ban the  
malloc instruction from returning a pointer to an alternate address  
space?

-Chris

On Nov 12, 2007, at 11:38 PM, Chris Lattner wrote:
>>> In an ideal world, we'll just need flags on load/
>>> store nodes because the pointer registers will already be lowered
to
>>> some other regclass.
>>
>> I assume malloc's and memcpy's would need them as well?
>
> Yeah, seems likely.  I think malloc gets lowered in SDISel to a call
> though, so maybe it doesn't need it.  I'm not sure what
"malloc from
> alternate address space" really means though.  There can only be one
> function named "malloc" :).
That's true. I guess I was thinking of "intrinsic" overloading,
but
you can't really do that based on return type, can you! Well, you  
could, but it'd be odd.
> Maybe LangRef should explicitly ban the
> malloc instruction from returning a pointer to an alternate address
> space?
Yes. I think that, in embedded C parlance, malloc should always  
return a pointer to the generic address space. If casting that  
pointer to another address space is valid given the target's rules,  
that's fine.

--
Christopher Lamb



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