I was trying to optimize our automatically generated backend for Open RISC and for this purpose I went through the
gcc torture testsuite.
There are many programs that are better optimized by LLVM, but some are much better optimized by gcc 4.9.
The main limitations were is loop unrolling and structures handling.
Differences can be best seen e.g. when compiling for an architecture such as MIPS, or by simply comparing the optimized LLVM IR
with code generated by gcc for MIPS. The tests with the most significant difference are listed here:
20010910-1.c (with LLVM from svn, this is even worse than LLVM 3.4)
20020206-2.c
20020402-2.c
* local arrays access
930526-1.c
pr32500.c
* merging same calls to one function to improve code size when optimized
931004-11.c
* better default inlining (probably)
pr19005.c
* other
pr46019.c
pr46909-1.c
We will try to improve some of these optimizations by ourselves, but I do not know when will we get to it, so I am posing it here,
so someone who would be interested in it can take a look at it.
Best regards
Adam Husar
P.S.: Also, if someone would be interested in our automatically generated LLVM backend, you can contact me,
or you can find additional details at www.codasip.com. We also provide a free academical license.
I can't recompile the auto declaration within FileManager.cpp using gcc
4.8 :
FileManager.cpp: In member function ‘const clang::FileEntry*
clang::FileManager::getFile(llvm::StringRef, bool, bool)’:
FileManager.cpp:311:10: warning: ‘auto’ changes meaning in C++11; please
remove it [-Wc++0x-compat]
for (auto & fe: SeenFileEntries) {
^
FileManager.cpp:311:17: warning: ISO C++ forbids declaration of ‘fe’
with no type [-fpermissive]
for (auto & fe: SeenFileEntries) {
^
FileManager.cpp:311:21: error: range-based ‘for’ loops are not allowed
in C++98 mode
for (auto & fe: SeenFileEntries) {
^
FileManager.cpp:312:14: error: request for member ‘getValue’ in ‘fe’,
which is of non-class type ‘int’
if (fe.getValue() == StaleFileEntry) {
^
FileManager.cpp:313:12: error: request for member ‘setValue’ in ‘fe’,
which is of non-class type ‘int’
fe.setValue(&UFE);
^
/usr/bin/rm: cannot remove
‘/home/Clang/src/tools/clang/lib/Basic/Debug+Asserts/FileManager.d.tmp’:
No such file or directory
make[4]: ***
[/home/Clang/src/tools/clang/lib/Basic/Debug+Asserts/FileManager.o] Error 1
make[4]: Leaving directory `/home/Clang/src/tools/clang/lib/Basic'
FileManager.cpp:311:10: warning: ‘auto’ changes meaning in C++11; please
remove it [-Wc++0x-compat]
for (auto & fe: SeenFileEntries) {
^
That message looks like one I'd expect if GCC was trying to compile
the file in C++98 mode (warning about the ancient use of "auto" as the
default for local variables). You could check that with a "make
VERBOSE=1" (at least for CMake), I expect there won't be a
"-std=c++11" option.
C++11 is needed these days (for anything after 3.4 theoretically, I
believe), but the build system should have added the appropriate
options to do this. I'd try a clean build.
FileManager.cpp:311:21: error: range-based for loops are not allowed
in C++98 mode
for (auto & fe: SeenFileEntries) {
^
FileManager.cpp:312:14: error: request for member getValue in fe,
which is of non-class type int
if (fe.getValue() == StaleFileEntry) {
^
solved by adding -std=c++11 to Makefile.config
Second one:
Compilation of "SmallPtrSet.cpp" seems to be broken ...
Solved by removing the conditional compile by
#ifdef LLVM_HAS_RVALUE_REDERENCE for method "SmallPtrSetImplBase"
>FileManager.cpp:311:21: error: range-based ‘for’ loops are not allowed
>in C++98 mode
>for (auto & fe: SeenFileEntries) {
>^
>FileManager.cpp:312:14: error: request for member ‘getValue’ in ‘fe’,
>which is of non-class type ‘int’
>if (fe.getValue() == StaleFileEntry) {
>^
FileManager.cpp:311:21: error: range-based ‘for’ loops are not allowed
in C++98 mode
for (auto & fe: SeenFileEntries) {
^
FileManager.cpp:312:14: error: request for member ‘getValue’ in ‘fe’,
which is of non-class type ‘int’
if (fe.getValue() == StaleFileEntry) {
^
Are you sure this is the 3.4.1 source?
Sorry ... I didn't realize that the "ROOT" group of CERN is using their
own git repository.
And the LLVM version for ROOT is patched for Cling !! So I was "barking
at the wrong tree" ... sorry.
FileManager.cpp:311:21: error: range-based ‘for’ loops are not allowed
in C++98 mode
for (auto & fe: SeenFileEntries) {
^
FileManager.cpp:312:14: error: request for member ‘getValue’ in ‘fe’,
which is of non-class type ‘int’
if (fe.getValue() == StaleFileEntry) {
^
Are you sure this is the 3.4.1 source?
Sorry ... I didn't realize that the "ROOT" group of CERN is using their
own git repository.
And the LLVM version for ROOT is patched for Cling !! So I was "barking
at the wrong tree" ... sorry.
Unfortunately cling is not part of LLVM and you should use the CERN vendor branch of llvm and clang. If there is enough user interest I can polish/generalize most of the patches and propose the project for inclusion. So far it seems not to be the case.
Vassil
I think the most-useful thing to do would be to file bug reports for these, with the original C code and the comparative analysis of the assembly for some in-tree target (such as MIPS). Please make sure to include exactly what optimization level and target you used, and if possible, some explanation of what should be done better.
