On Mon, 23 Nov 2009, Szak�ts Viktor wrote: > Hi Przemek, Tamas and All, > After reading the conversion now I totally don't > understand what is the situation with LLVM-GCC.
The situation is very simple. llvm-ar cannot work correctly with llvm-gc and it's a bug in this tools. It doesn't matter what type of object is generated. I.e. in ICC where 'xiar' is used instead of 'ar' we can use archives which contains meta code for link time IPO without any problems. In LLVM not and without any doubts it's sth what should be fixed by LLVM compiler authors or packagers who create binary packages for given distribution. That's all. As long as it will not be resolved then it's necessary to use different hacks which allows to link into final application binary compiled with and without meta code or using some new extensions. In general link time IPO is very simple idea. Instead of creating final machine code during compilation phase some meta code is generated which can be reused for farther optimizations during linking. In most of cases such optimization is simple autoinlining and then optimizing final function which contains inlined code. In general it's exactly the same job as done at compile time but allows to inline functions from different .o/.obj. Because we are compiling time critical part of HVM code as single hvmall.c file then it's fully optimized at compile time and using link time IPO does not improve overall performance in this code at all. It can only help in some external function calls but this is minor part of executed code so the difference is also very small. Returning to link time IPO. Compiler has to generate meta code and store it in object files. Sometimes it generates code in two versions as native machine code and meta code and store it in single file so linker can choose the preferred version, i.e. when link time optimizations are disabled then it uses directly machine code and ignores meta code. Library tools should understand extended object file formats and create valid libraries. They can be extended to create more complicated indexes in final libraries which can improve the performance of link time optimizations. Finally linker has to understand new object file formats and new library formats with extended information if any. So far this functionality is not present in LLVM-GCC. For some reasons llvm-gcc uses internally native 'ld' though as parameters it receives files in new format (i.e. libraries with new indexes or byte code files compiled with -O4 switch) which are not recognized by native 'ld' so as workaround we have to make some tricks to force using llvm-ld. I hope that in the future llvm-gc will recognize file format automatically so it can be used like ICC or other compilers which supports link time optimization using meta code store din object files. BTW new version of GCC will also support IPO when -O4 optimization is used and LLVM-GCC already accepts this switch which can be used to force generating byte code instead of machine code in .o files. Anyhow it also does not help to resolve the link time problem and even with -O4 and .o files containing byte code still native 'ld' is used instead of llvm-ld :-( best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
