empty loop elimination (lack of) ?
Cyrille Chepelov
cyrille@chepelov.org
Mon Jan 28 14:59:00 GMT 2002
Hi,
while testing some code on Borland C++, and as a matter of cross-checking,
I've found that there is an opportunty for optimisation that g++ misses
(bcc32 also, but that is off-topic).
Consider the attached loop-destroy.cpp file, in particular the compilation
of List<int>::isValid(). gcc (2.95.3 and 3.0.3 on ix86 give me the following
results (with -O3):
_isValid__Ct4List1Zi:
pushl %ebp
xorl %eax,%eax
movl %esp,%ebp
.align 4
L15:
incl %eax
cmpl $3,%eax
jbe L15
movl %ebp,%esp
movb $1,%al
popl %ebp
ret
... including an empty, useless stunt with %eax, which is finally replaced
with the contents of the last movb. (There is also some games with %esp and
%ebp, which don't look totally useful, but 3.0.3 looks better than 2.95.3
with that respect).
(in case you wonder, bcc32 makes even more stupid things).
Compiling with -O3 -funroll-loops gives this:
_isValid__Ct4List1Zi:
pushl %ebp
movb $1,%al
movl %esp,%ebp
movl %ebp,%esp
popl %ebp
ret
.. somewhat better, still some stuff which probably ought to be optimised.
As a point of comparison, VC++ 6.0 is completely inlining this stuff (with
fairly default optimisations) into a single (true) constant. Just as what
g++ does when the original function is simply a "return true;"
2.95.3 and 3.0.3 give the same results, give or take a movl %ebp,%esp.
1) How hard would it be to notice that the loop is empty and produces no
useful results (without unrolling it), and then to remove it ?
2) How hard would it be to re-do an inlining pass once the loop
unrolling/empty loop removal pass has been done ?
3) How hard would it be to omit stack frames whenever there is no
dereference in a tail function ? Wouldn't that be a sensible default ?
I'd be more than happy to give that a try, if someone gently shows me where
to fiddle with (no warranties, though).
-- Cyrille
For comparison's sake, there is a tarball at
http://www.chepelov.org/cyrille/loop-destroy.tar.gz, which contains this
.cpp file, and assembly outputs of a few compilers.
--
Grumpf.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loop-destroy.cpp
Type: text/x-c++src
Size: 580 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20020128/46fc4e64/attachment.bin>
More information about the Gcc
mailing list