[LLVMdev] overflow + saturation stuff

[Jonas Maebe]

On 08 Feb 2009, at 14:41, Gordon Henriksen wrote:

> On 2009-02-08, at 05:59, Jonas Maebe wrote:
>
>> The proposal suggests to change/split the existing sub/add/mul
>> opcodes. This makes me wonder to what extent it is (currently, or
>> ever) advisable for an external compiler to generate LLVM IR. Is
>> there a plan to stabilise at some point and guarantee backwards
>> compatibility to a certain extent, or should compilers that are not
>> integrated in the LLVM infrastructure always target one particular
>> release of LLVM?
>
> LLVM does guarantee backwards compatibility with compiled bitcode. The
> C++ interfaces are not frozen, so you may need to upgrade code
> targeting LLVM when upgrading; reasonable efforts are made to avoid
> making this process painful.

Sorry for being unclear: I did not mean the C++ interface nor compiled  
bitcode, but the LLVM IR "assembler" interface (i.e., the .s files  
that llvm-gcc generats with "-emit-llvm -S").

> Of course, what code is contributed to
> the project will be maintained through these changes.

In our case, I doubt that would happen since it's a self-hosting  
Pascal compiler (with several other code generators besides the under- 
development LLVM backend).

But basically, if I understand you correctly: the correct interface  
would be compiled bitcode rather than the "assembler" level interface?


Jonas