search for: func_code_inst_stor

..., 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...

...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...

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

...'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 c...