[LLVMdev] C embedded extensions and LLVM

[Chris Lattner]

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/