Hi,
Can anyone suggest any reasons why this seemingly-innocuous (though
stupid-looking) excerpt from gnu fileutils 4.1 would make llvm-gcc
go so incredibly slowly? It doesn't seem to be a question of the
size of the output.
Here's what I do:
% time llvm-gcc -c sha24.c
56.840u 0.050s 1:07.05 84.8% 0+0k 0+0io 1050pf+0w
% ls -l sha24.o
-rw-r--r-- 1 brg brg 5784 2002-12-14 07:43 sha24.o
The problem goes away if I use -S:
% time llvm-gcc -S sha24.c
0.060u 0.010s 0:00.09 77.7% 0+0k 0+0io 548pf+0w
sha24.c (5.3 KB)
Can anyone suggest any reasons why this seemingly-innocuous (though
stupid-looking) excerpt from gnu fileutils 4.1 would make llvm-gcc
go so incredibly slowly? It doesn't seem to be a question of the
size of the output.
I'll look into it. That is a very, uh, interesting code snippet 
-Chris
Here's what I do:
% time llvm-gcc -c sha24.c
56.840u 0.050s 1:07.05 84.8% 0+0k 0+0io 1050pf+0w
% ls -l sha24.o
-rw-r--r-- 1 brg brg 5784 2002-12-14 07:43 sha24.o
The problem goes away if I use -S:
% time llvm-gcc -S sha24.c
0.060u 0.010s 0:00.09 77.7% 0+0k 0+0io 548pf+0w
-Chris
Can anyone suggest any reasons why this seemingly-innocuous (though
stupid-looking) excerpt from gnu fileutils 4.1 would make llvm-gcc
go so incredibly slowly? It doesn't seem to be a question of the
size of the output.
As it turns out, it was (suprisingly) the reassociate pass that was taking
the huge amounts of time. This is fixed by applying these two patches:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20021209/001946.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20021209/001947.html
The first patch is just a cleanup patch which simplifies moving an
instruction, the second fixes the problem by introducing a cache to avoid
some pretty incredible recomputation for this testcase.
Thanks for finding this, in my debug build, reassociate went from taking
27 seconds on this testcase to .35
-Chris