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

Hi,

Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven:
1) Download llvm-gcc4 binary and llvm. Compile and run make check.

I did a debug build on OSX 10.4.9 and everything went fine.

Results of "make check" (see ppc.log):

                 ===  Summary ==
# of expected passes            1630
# of unexpected failures       21
# of expected failures            2


3) Compile llvm-gcc4 and llvm from source. Run 'make check'.

On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build  
with the header files using uintptr_t (not recognised as a type).  
Putting "#include <stdint.h>" in include/llvm/BasicBlock.h
(llvm) and
in "include/llvm/ValueSymbolTable.h" (frontend) resolved this.

Also, I got linking errors while linking tblgen (see error.txt). Any  
ideas about this?

Results of "make check" (without tblgen; see x86.log):

                 ===  Summary ==# of expected passes            1423
# of unexpected failures        25
# of expected failures            3

It would also be helpful for someone to compile/test with objdir !=  
srcdir.

Both builds above happened in a directory separate from the source  
directory.

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?

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.:
  * SymbolTable.h has vanished
  * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by  
Type::Int8Ty, ... How does one keep code portable with the various  
TypeIntXTy's?
  * GetElementPtrInst's constructor doesn't accept an std::vector  
anymore but requires explicit arguments.
  * CastInst is now abstract and its functionality is split into  
several parts. What to choose when casting a pointer to a double  
pointer? Is it always clear which cast instruction is the right one  
(e.g. when exact Value is only known at run-time)?
  * 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?
  * The same goes for BasicBlock::getNext()/Prev(). Is iterating  
through the parent Function's iterator the only solution?
  * CallInst's constructors do not accept vectors anymore, but a  
double pointer (!) instead. Why?
  * Module::getNamedFunction() is now called Module::getFunction().
  * llvm/Transforms/Utils/Cloning.h's CloneFunctionInto() needs a  
DenseMap as its third argument instead of an STL map.
  * Pass's constructor now needs an intptr_t as explained in the  
updated "Write your first pass"-document.
  * In my own code, I can't use cout anymore without the std:: prefix.
  * ConstantBool/Integral/Int are merged into ConstantInt.
  * %llvm.dbg.subprogram.type's line number is now the 7th element;  
its compile unit is now the 6th element.
  * Argument names have got their argument index appended to their  
name in the LLVM bitcode (e.g. "define void @f(i32 %Arg1, i32 % 
OtherArg2) {...}" instead of "define void @f(i32 %Arg, i32 %OtherArg)
{...}").
  * ... (there is probably more, as my app compiles by now, but is  
still broken)

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070517/384cf38a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.zip
Type: application/zip
Size: 40502 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070517/384cf38a/attachment.zip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070517/384cf38a/attachment-0001.html>

On Thu, 2007-05-17 at 23:07 +0200, Bram Adams wrote:
> Hi,
> 
> 
> Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven:
> 1) Download llvm-gcc4 binary and llvm. Compile and run make check.
> 
> 
> I did a debug build on OSX 10.4.9 and everything went fine.
Good.
> 
> 
> Results of "make check" (see ppc.log):
> 
> 
>                 ===  Summary ==> 
> 
> # of expected passes            1630
> # of unexpected failures       21
> # of expected failures            2
This doesn't look like there's enough tests. The total number should be
in the high 1900s. Did you configure with only the PPC target?
> 
> 3) Compile llvm-gcc4 and llvm from source. Run 'make check'.
> 
> 
> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build
> with the header files using uintptr_t (not recognised as a type).
> Putting "#include <stdint.h>" in include/llvm/BasicBlock.h
(llvm) and
> in "include/llvm/ValueSymbolTable.h" (frontend) resolved this.
This isn't the correct solution :)  We don't (or try not) to include
system headers anywhere except lib/System and a few spots in
include/llvm/Support. The case in point is
include/llvm/Support/DataTypes.h.  Please adjust
include/llvm/Support/DataTypes.h to accommodate this operating system
and send the patch to llvm-commits mailing list. We'll include it so
that LLVM can compile on Slackware 10.2 with gcc 3.3.6. 

... snip ...
Others have responded to the rest.

Reid.
>

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/

> 3) Compile llvm-gcc4 and llvm from source. Run 'make check'.
>
> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build with 
> the header files using uintptr_t (not recognised as a type). Putting 
> "#include <stdint.h>" in include/llvm/BasicBlock.h (llvm)
and in
> "include/llvm/ValueSymbolTable.h" (frontend) resolved this.
>
> Also, I got linking errors while linking tblgen (see error.txt). Any ideas 
> about this?
I'll look into these two in a bit. Thanks!
> Results of "make check" (without tblgen; see x86.log):
>
>                ===  Summary ==> #  of expected passes            1423
> #  of unexpected failures        25
> #  of expected failures            3
Can you verify that you have llvm-gcc in your path and that its the 2.0 
llvm-gcc? The errors are mostly saying the tests couldnt find llvm-gcc and 
also the path looked like a 1.9 one.

Thanks,
Tanya
>
> It would also be helpful for someone to compile/test with objdir != 
> srcdir.
>
> Both builds above happened in a directory separate from the source 
> directory.
>
> 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?
>
> 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.:
>   * SymbolTable.h has vanished
>   * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by 
> Type::Int8Ty, ... How does one keep code portable with the various 
> TypeIntXTy's?
> * GetElementPtrInst's constructor doesn't accept an std::vector
anymore
> but requires explicit arguments.
> * CastInst is now abstract and its functionality is split into several 
> parts. What to choose when casting a pointer to a double pointer? Is it 
> always clear which cast instruction is the right one (e.g. when exact 
> Value is only known at run-time)?
> * 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?
> * The same goes for BasicBlock::getNext()/Prev(). Is iterating through 
> the parent Function's iterator the only solution?
> * CallInst's constructors do not accept vectors anymore, but a double 
> pointer (!) instead. Why?
>   * Module::getNamedFunction() is now called Module::getFunction().
>   * llvm/Transforms/Utils/Cloning.h's CloneFunctionInto() needs a 
> DenseMap as its third argument instead of an STL map.
> * Pass's constructor now needs an intptr_t as explained in the updated 
> "Write your first pass"-document.
>   * In my own code, I can't use cout anymore without the std:: prefix.
>   * ConstantBool/Integral/Int are merged into ConstantInt.
>   * %llvm.dbg.subprogram.type's line number is now the 7th element; 
> its compile unit is now the 6th element.
> * Argument names have got their argument index appended to their name in 
> the LLVM bitcode (e.g. "define void @f(i32 %Arg1, i32 %OtherArg2)
{...}"
> instead of "define void @f(i32 %Arg, i32 %OtherArg) {...}").
> * ... (there is probably more, as my app compiles by now, but is still 
> broken)
>
> Kind regards,
>
> Bram Adams
> GH-SEL, INTEC, Ghent University (Belgium)
> 
>

> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build with the
> header files using uintptr_t (not recognised as a type). Putting
"#include
> <stdint.h>" in include/llvm/BasicBlock.h (llvm) and in 
> "include/llvm/ValueSymbolTable.h" (frontend) resolved this.
Ok. This is now fixed on the release branch. Thanks!
> Also, I got linking errors while linking tblgen (see error.txt). Any ideas 
> about this?
I'm not really sure whats going on here and I can't reproduce this since
I
don't have your setup. Its probably either an issue with gcc or ld (try 
upgrading to 2.17.X if possible). If you can try to investigate it 
further, that would be great. Then file a bug for it.

Otherwise, I think the make check errors are ok given it can't find 
llvm-gcc.

Thanks!
-Tanya
>
> Results of "make check" (without tblgen; see x86.log):
>
>                ===  Summary ==> #  of expected passes            1423
> #  of unexpected failures        25
> #  of expected failures            3
>
> It would also be helpful for someone to compile/test with objdir != srcdir.
>
> Both builds above happened in a directory separate from the source
directory.
>
> 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?
>
> 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.:
>   * SymbolTable.h has vanished
>   * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by 
> Type::Int8Ty, ... How does one keep code portable with the various 
> TypeIntXTy's?
> * GetElementPtrInst's constructor doesn't accept an std::vector
anymore but
> requires explicit arguments.
> * CastInst is now abstract and its functionality is split into several 
> parts. What to choose when casting a pointer to a double pointer? Is it 
> always clear which cast instruction is the right one (e.g. when exact Value
> is only known at run-time)?
> * 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?
> * The same goes for BasicBlock::getNext()/Prev(). Is iterating through the 
> parent Function's iterator the only solution?
> * CallInst's constructors do not accept vectors anymore, but a double 
> pointer (!) instead. Why?
>   * Module::getNamedFunction() is now called Module::getFunction().
>   * llvm/Transforms/Utils/Cloning.h's CloneFunctionInto() needs a 
> DenseMap as its third argument instead of an STL map.
> * Pass's constructor now needs an intptr_t as explained in the updated 
> "Write your first pass"-document.
>   * In my own code, I can't use cout anymore without the std:: prefix.
>   * ConstantBool/Integral/Int are merged into ConstantInt.
>   * %llvm.dbg.subprogram.type's line number is now the 7th element; 
> its compile unit is now the 6th element.
> * Argument names have got their argument index appended to their name in
the
> LLVM bitcode (e.g. "define void @f(i32 %Arg1, i32 %OtherArg2)
{...}" instead
> of "define void @f(i32 %Arg, i32 %OtherArg) {...}").
> * ... (there is probably more, as my app compiles by now, but is still 
> broken)
>
> Kind regards,
>
> Bram Adams
> GH-SEL, INTEC, Ghent University (Belgium)
> 
>

Hi,

Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven:
>> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build  
>> with the header files using uintptr_t (not recognised as a type).  
>> Putting "#include <stdint.h>" in
include/llvm/BasicBlock.h (llvm)
>> and in "include/llvm/ValueSymbolTable.h" (frontend) resolved
this.
>
> Ok. This is now fixed on the release branch. Thanks!
The strange thing is that the configure process defines:

#define HAVE_STDINT_H 1

However, without literally including stdint.h (which should be  
avoided as Reid mentioned) the compilation of AsmWriter.cpp goes  
wrong, although stdint.h, llvm/Support/DataTypes.h and inttypes.h are  
all mentioned in AsmWriter.d:

if g++ -I/home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/ 
VMCore -I/home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore -I/ 
home/bram/workspace/svn/aspicere2/trunk/llvm-build/include -I/home/ 
bram/workspace/svn/aspicere2/trunk/llvm/include -I/home/bram/ 
workspace/svn/aspicere2/trunk/llvm-build/include -I/home/bram/ 
workspace/svn/aspicere2/trunk/llvm/include  -D_GNU_SOURCE - 
D__STDC_LIMIT_MACROS -g -fno-exceptions -D_DEBUG  -Woverloaded- 
virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused - 
Wno-unused-parameter  -c -MD -MT /home/bram/workspace/svn/aspicere2/ 
trunk/llvm-build/lib/VMCore/Debug/AsmWriter.o -MP -MF /home/bram/ 
workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore/Debug/ 
AsmWriter.LACXXd /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/ 
VMCore/AsmWriter.cpp -o /home/bram/workspace/svn/aspicere2/trunk/llvm- 
build/lib/VMCore/Debug/AsmWriter.o ;\
   then /usr/bin/mv -f "/home/bram/workspace/svn/aspicere2/trunk/llvm- 
build/lib/VMCore/Debug/AsmWriter.LACXXd" "/home/bram/workspace/svn/ 
aspicere2/trunk/llvm-build/lib/VMCore/Debug/AsmWriter.d"; \
   else /usr/bin/rm -f "/home/bram/workspace/svn/aspicere2/trunk/llvm- 
build/lib/VMCore/Debug/AsmWriter.LACXXd"; exit 1; fi
In file included from /home/bram/workspace/svn/aspicere2/trunk/llvm/ 
include/llvm/Function.h:22,
                  from /home/bram/workspace/svn/aspicere2/trunk/llvm/ 
include/llvm/Module.h:17,
                  from /home/bram/workspace/svn/aspicere2/trunk/llvm/ 
include/llvm/Assembly/PrintModulePass.h:22,
                  from /home/bram/workspace/svn/aspicere2/trunk/llvm/ 
lib/VMCore/AsmWriter.cpp:18:
/home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/ 
BasicBlock.h: In
    static member function `static unsigned int
    llvm::BasicBlock::getInstListOffset()':
/home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/ 
BasicBlock.h:197: error: syntax
    error before `;' token
...

Should -DHAVE_STDINT_H be passed to the above command?
>
>> Also, I got linking errors while linking tblgen (see error.txt).  
>> Any ideas about this?
>
> I'm not really sure whats going on here and I can't reproduce this
> since I don't have your setup. Its probably either an issue with  
> gcc or ld (try upgrading to 2.17.X if possible). If you can try to  
> investigate it further, that would be great. Then file a bug for it.
Problem solved: compiling the 2.0 frontend from source had resulted  
in gcc, g++, ... instead of llvm-gcc, llvm-g++, ... After manually  
renaming them, compilation of LLVM was a breeze and the tests did not  
yield any unexpected failures (see attachment).

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x86.log.zip
Type: application/zip
Size: 19787 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070518/d14c6703/attachment.zip>

Hi,

Op 18-mei-07, om 00:11 heeft Chris Lattner het volgende geschreven:
> 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.
OK, I'll try out the latter (and wait for Leopard in the meantime :-)).
> This is all very useful.  If you have any more additions, please  
> let me
> know.  Thanks again,
You're welcome, here's some more:
  * The various IntXTy's are not considered primitive anymore by e.g.  
Type::isPrimitiveType().
  * It seems that a C-call like printf("---\n") is transformed to puts
("---") in the LLVM IR instead of keeping it a printf. What are the  
circumstances in which this happens? Do other similar conversions  
occur? Can this be turned off (lower optimisation level?)? Manually  
replacing the puts-calls by a printf-call is not straightforward, as  
the argument should be appended a '\n' (implicit with puts).

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

Hello, Bram
>   * It seems that a C-call like printf("---\n") is transformed to
puts
> ("---") in the LLVM IR instead of keeping it a printf. What are
the
> circumstances in which this happens? Do other similar conversions  
> occur? Can this be turned off (lower optimisation level?)? Manually  
> replacing the puts-calls by a printf-call is not straightforward, as  
> the argument should be appended a '\n' (implicit with puts).
This transformation is performed via simplify-libcalls optimization
pass. You can look into corresponding source to check for list of
xforms.

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On Sat, 19 May 2007, Anton Korobeynikov wrote:
>>   * It seems that a C-call like printf("---\n") is
transformed to puts
>> ("---") in the LLVM IR instead of keeping it a printf. What
are the
>> circumstances in which this happens? Do other similar conversions
>> occur? Can this be turned off (lower optimisation level?)? Manually
>> replacing the puts-calls by a printf-call is not straightforward, as
>> the argument should be appended a '\n' (implicit with puts).
> This transformation is performed via simplify-libcalls optimization
> pass. You can look into corresponding source to check for list of
> xforms.
Anton is right.  You should be able to use -fno-builtins to disable this.

-Chris

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