On Nov 11, 2007, at 9:52 AM, Chris Lattner wrote:> > On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > >> I've been playing around with clang/LLVM looking at adding partial >> support for the draft technical report for embedded C extensions >> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n1169.pdf), specifically named address spaces. >> >> Named address spaces need to be tracked in LLVM in essentially all >> the same places that alignment is tracked, > > Others addressed the other questions, one (surprising?) thing I'd > recommend: > > Unlike alignment and volatility, I think that the address space > qualifier should be represented explicitly in the type system. The > reason for this is primarily that pointers to different address > spaces are really very different sorts of beasties: for example > they can be codegen'd to have different sizes.Very true.> 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 intrinsic)?> The good thing about this is that I think it will make it > substantially easier to update the various llvm optimizations if > you do this.Bonus!> 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. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071111/652f9a0b/attachment.html>
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.>> 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. -Chris
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>
> This should just be a bitcast from one pointer to another pointer type.Here's a likely counterexample: the AVR (8 bit embedded) has a byte-addressed data space and word-addressed code space. Legal C code involving pointer casts can confuse all known versions of avr-gcc into generating bad function pointer code that jumps to twice the address of the intended target. Last I heard there's no real plan to fix this. While the embedded C standard permits a way out where the compiler understands that code space and data space pointers are different, I don't see any way that pointer casts (for example, from an unqualified pointer to either code ptr or data ptr) can be nops. John Regehr