[LLVMdev] C embedded extensions and LLVM
christopher.lamb at gmail.com
Mon Nov 12 23:28:36 PST 2007
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.
>> Does supporting those casts require an explicit operation (ie
> This should just be a bitcast from one pointer to another pointer
>>> 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.
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev