[LLVMdev] C embedded extensions and LLVM

[Christopher Lamb]

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>