[LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online)

[Chris Lattner]

On Thu, 17 May 2007, Bram Adams wrote:
> About LTO support: the new release documents don't mention anything about 
> this. Also, the relevant bugzilla entries I could find date back to March 
> 2007. Has any progress been made recently in adding LTO to the Darwin linker 
> and/or GNU binutils?

I'll mention this in the release notes.  The darwin linker in 10.5 (not 
yet released) supports llvm, and there is an experimental patch for 
binutils, but I don't knows its current state.

> About porting from 1.9 to 2.0: it would be helpful to have some kind of 
> porting guide as I encountered a lot of API changes, e.g.:

This is all great information, I'm merging this into the release notes.

>   * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by 
> Type::Int8Ty, ... How does one keep code portable with the various 
> TypeIntXTy's?

LLVM integer types have always been fixed size.  "long" didn't correspond 
to C's "long" type, it was always 64-bits.

> * CastInst is now abstract and its functionality is split into several 
> parts. What to choose when casting a pointer to a double pointer?

pointer to pointer casts are always bitcast.

> Is it 
> always clear which cast instruction is the right one (e.g. when exact Value 
> is only known at run-time)?

Yep. :)

> * Instruction::getNext()/Prev() have suddenly become private, seemingly 
> without fast, easy to use alternative. Is iterating through the parent 
> BasicBlock's iterator the only solution?

Yes.  The next/prev pointers have extra information encoded in them now, 
for efficiency. The iterator takes care of this for you, deferencing the 
raw pointer wouldn't work even if you could get to it.

> * The same goes for BasicBlock::getNext()/Prev(). Is iterating through the 
> parent Function's iterator the only solution?

Yep.

> * CallInst's constructors do not accept vectors anymore, but a double 
> pointer (!) instead. Why?

Most calls have been changed to take a range instead of a vector instead. 
This allows you to do things like this:

   Value *Ops[] = { Op1, Op2, Op3 };
   new Whatever(Ops, 3);

which avoids creating a temporary vector.

>   * In my own code, I can't use cout anymore without the std:: prefix.

You should have always used std:: :)

> * ... (there is probably more, as my app compiles by now, but is still 
> broken)

This is all very useful.  If you have any more additions, please let me 
know.  Thanks again,

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/