[LLVMdev] Undocumented API changes

Mark Shannon marks at dcs.gla.ac.uk
Wed Jun 17 12:06:44 PDT 2009


Why are there so many undocumented (and as I far I can see) unnecessary 
API changes?

Recently there has been:

For JIT applications, please include llvm/Target/TargetSelect.h and
call the llvm::InitializeNativeTarget() function before creating an EE.

The major CHANGE is:  the JIT will no longer be safe for executing
threaded applications without first invoking llvm_start_multithreaded(). 
  Please begin to update your client applications now if this affects 
you, as I will be throwing the switch in SVN sooner rather than later.

The change you should make: every call to addPassesToEmitFile,
addPassesToEmitFileFinish, addPassesToEmitMachineCode, or
addCommonCodeGenPasses should pass an optimization level enum rather
than true / false for "Fast". The enum is in

namespace CodeGenOpt {
   enum Level {

The LLVM IR opcodes Add, Sub, and Mul have been each split into two. 
Add, Sub, and Mul now only handle integer types, and three new opcodes, 
FAdd, FSub, and FMul now handle floating-point types.

And that's just in a few days!

I recently tried to build my compiler-generator with the svn-head 
version of llvm.
No chance.
It wouldn't build, thanks to (3) above.
Once I got it to build, it crashed.
It all works just fine with 2.5.

I spent a lot of time and effort, getting things to work, first with 
2.4, then with 2.5 (The changes in the API between 2.4 and 2.5 were more 
than I would have liked, but mainly renaming and caught by the compiler).

Remember, its not just gcc-llvm and clang that use llvm.

So please treat the API with respect.
Don't change it often, and document EACH and EVERY change.


Change (1) above seems to be pointless.
Why can't the code to create the EE, just call 


More information about the llvm-dev mailing list