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. 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. > > 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. 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?I've come across a hitch. Store instructions do not reference the pointer type in the .bc format, only the stored type. The .bc reader constructs the pointer type from the stored value's type. This means that the address space information doesn't come along for the ride. I see three solutions: 1) Change how stores are written/read in .bc to store the pointer type rather than the stored type. This is the most straight forward, but I think it also breaks .bc compatibility in a way that's impossible to work around. There's no way to differentiate the new and old forms. 2) Have an extended record form of stores that carries the address space information for the pointer type which then gets restored by the reader. This preserves backwards compatibility, but is kind of ugly. 3) Store address space information on all types (not just pointers), but it only really affects how pointers are handled. This ensures that address spaces go wherever the type goes. This is pretty invasive, and I'd like to avoid that overhead if at all possible. My suggestion would be 2 for now with an intention to change to 1 in LLVM 3.0. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071121/bd553af1/attachment.html>
On Wed, 21 Nov 2007, Christopher Lamb wrote:>> Unlike alignment and volatility, I think that the address space qualifier >> should be represented explicitly in the type system. The reason for this> I've come across a hitch. Store instructions do not reference the pointer > type in the .bc format, only the stored type. The .bc reader constructs the > pointer type from the stored value's type. This means that the address space > information doesn't come along for the ride.Ah, that is annoying. :(> I see three solutions: > > 1) Change how stores are written/read in .bc to store the pointer type rather > than the stored type. This is the most straight forward, but I think it also > breaks .bc compatibility in a way that's impossible to work around. There's > no way to differentiate the new and old forms.I strongly prefer this approach. Implementing this without breaking old .bc files is actually pretty simple. Just add a new "FUNC_CODE_INST_STORE2" record, and define it however you want (with a new, previously unused, ID #). The reader should read both FUNC_CODE_INST_STORE (which can't involved addr spaces) and FUNC_CODE_INST_STORE2 (which can). The .bc writer can switch to unconditionally writing out stores in FUNC_CODE_INST_STORE2 format. Please add a generous block comment to llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum explaining what the difference is though. :) Thanks Christopher, -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Nov 21, 2007, at 6:22 PM, Chris Lattner wrote:> On Wed, 21 Nov 2007, Christopher Lamb wrote: >>> Unlike alignment and volatility, I think that the address space >>> qualifier >>> should be represented explicitly in the type system. The reason >>> for this > >> I've come across a hitch. Store instructions do not reference the >> pointer >> type in the .bc format, only the stored type. The .bc reader >> constructs the >> pointer type from the stored value's type. This means that the >> address space >> information doesn't come along for the ride. > > Ah, that is annoying. :( > >> I see three solutions: >> >> 1) Change how stores are written/read in .bc to store the pointer >> type rather >> than the stored type. This is the most straight forward, but I >> think it also >> breaks .bc compatibility in a way that's impossible to work >> around. There's >> no way to differentiate the new and old forms. > > I strongly prefer this approach. Implementing this without > breaking old > .bc files is actually pretty simple. Just add a new > "FUNC_CODE_INST_STORE2" record, and define it however you want (with a > new, previously unused, ID #). > > The reader should read both FUNC_CODE_INST_STORE (which can't involved > addr spaces) and FUNC_CODE_INST_STORE2 (which can). The .bc writer > can > switch to unconditionally writing out stores in FUNC_CODE_INST_STORE2 > format. > > Please add a generous block comment to > llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum explaining > what the difference is though. :)Should I take the same approach to the encoding of pointer types in the pointer table? -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071124/7ca3547e/attachment.html>