This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
gcc 3.0 generates abysmal asm for bytecode emulator (bad register policy)
- To: gcc at gcc dot gnu dot org
- Subject: gcc 3.0 generates abysmal asm for bytecode emulator (bad register policy)
- From: Denys Duchier <Denys dot Duchier at ps dot uni-sb dot de>
- Date: 09 Mar 2001 23:15:45 +0100
I have (fairly recently) started tracking gcc 3.0 to follow its impact
on our system (an implementation of a programming language, using a
(threaded) bytecode emulator).
Our system compiled with gcc 3.0 is so much slower than when compiled
with gcc 2.95.3 that this has become a serious concern. For example,
on one benchmark it is slower by a factor of 1.4.
One problem is with the code generated for the bytecode emulator
loop. This is implemented, using the usual threaded code technique,
in a procedure with many labels; one for each bytecode instruction.
At the end of each instruction, we jump directly to the label
implementing the next instruction.
I looked at the assembly code generated by "c++ -fno-exceptions -O3
-fstrict-aliasing -fomit-frame-pointer" and among other things it
appears that it is attempting to keep one constant in a register.
That constant is the address of the table entry containing the boolean
"true" value of our language. This is very bad, especially on a
register-poor architecture like intel. While the "true" value is used
in many places in the emulator loop, these places are not related by
control flow: each bytecode instruction is implemented by a small
sequence of instructions and at the end of this sequence we jump to an
arbitrary and unrelated label implementing a different instruction.
The consequence of trying to keep that constant in a register is that
a very large fraction of the code is devoted to maintaining that
invariant. An invariant which is not only useless in our case, but
downright harmful.
What's going on? Is there any hope that this can be fixed? Is there
a workaround?
Cheers,
PS: I can supply our code to allow the problem to be reproduced, but
it's rather big
--
Dr. Denys Duchier Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme (Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45 http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50 Phone: +49 681 302 5618
66041 Saarbruecken, Germany Fax: +49 681 302 5615