llvm dev - Jun 2014 - [LLVMdev] problems to recompile LLVM version 3.4.1 with gcc48 / SuSE 13.1

Hello!

   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:

* loop unrolling

20000422-1.c
20000412-6.c
20050224-1.c
20000412-4.c
20100416-1.c
950714-1.c
pending-4.c

* structures

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.

Hi,

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'


Is there a patch available ?

--Armin

Hi Armin,

On 10 June 2014 12:15, Armin Steinhoff <as at steinhoff-automation.com>
wrote:
> 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.

Cheers.

Tim.

Hi,

first problem was:
>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"

Hope it doesn't break anything :)


BTW .. is "cling" now integral part of LLVM ?

Regards

--Armin

Did we accidentally apply C++11 patches to 3.4.1?


On Thu, Jun 12, 2014 at 1:57 AM, Armin Steinhoff <
as at steinhoff-automation.com> wrote:
>
> Hi,
>
> first problem was:
>
> >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"
>
> Hope it doesn't break anything :)
>
>
> BTW .. is "cling" now integral part of LLVM ?
>
> Regards
>
> --Armin
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140612/a2488e83/attachment.html>

On Thu, Jun 12, 2014 at 10:57:46AM +0200, Armin Steinhoff
wrote:
> 
> Hi,
> 
> first problem was:
> 
> >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?  This doesn't seem to match what
is in SVN:
https://llvm.org/viewvc/llvm-project/cfe/tags/RELEASE_34/dot1-final/lib/Basic/FileManager.cpp?revision=208032&view=markup

-Tom
> 
> 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"
> 
> Hope it doesn't break anything :)
> 
> 
> BTW .. is "cling" now integral part of LLVM ?
> 
> Regards
> 
> --Armin
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi,

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.

 -Hal

----- Original Message -----
> From: husar at codasip.com
> To: llvmdev at cs.uiuc.edu
> Sent: Tuesday, June 10, 2014 4:49:05 AM
> Subject: [LLVMdev] Suggestions for optimizations
> 
> Hello!
> 
>    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:
> 
> * loop unrolling
> 
> 20000422-1.c
> 20000412-6.c
> 20050224-1.c
> 20000412-4.c
> 20100416-1.c
> 950714-1.c
> pending-4.c
> 
> * structures
> 
> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory