[LLVMdev] C embedded extensions and LLVM

[Christopher Lamb]

On Nov 24, 2007, at 7:47 PM, Christopher Lamb wrote:

>
> 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 have said:

> Should I take the same approach to the encoding of pointer types in  
> the types table?

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071124/3e4fde9b/attachment.html>