Related articles |
---|
[2 earlier articles] |
Re: GCC does not cope with my code webid@asi.fr (Armel) (2000-05-28) |
Re: GCC does not cope with my code chrisd@reservoir.com (Chris Dodd) (2000-05-28) |
Re: GCC does not cope with my code rus@tamu.edu (Silvius Rus) (2000-05-28) |
Re: GCC does not cope with my code bonzini@gnu.org (2000-05-28) |
Re: GCC does not cope with my code gnb@itga.com.au (Gregory Bond) (2000-05-28) |
Re: GCC does not cope with my code J.Scheerder@cwi.nl (2000-05-28) |
Re: GCC does not cope with my code Wilco.Dijkstra@arm.com (Wilco Dijkstra) (2000-05-28) |
Re: GCC does not cope with my code braung@ert.rwth-aachen.de (Gunnar Braun) (2000-05-31) |
Re: GCC does not cope with my code bosch@nile.gnat.com (Geert Bosch) (2000-06-04) |
From: | Wilco Dijkstra <Wilco.Dijkstra@arm.com> |
Newsgroups: | comp.compilers |
Date: | 28 May 2000 21:07:11 -0400 |
Organization: | Compilers Central |
Keywords: | GCC, practice |
Gunnar Braun wrote:
> The
> problem is that the (source) file (after the macro expansion) isn't
> really large, it's below 700 kB. If the file gets above 700 kB, the
> compiler crashes with the famous signal 11 internal compiler error.
Files of > 1MBytes are not uncommon, but functions of that size are!
> What is wrong with the generated source file that the compiler doesn't
> cope with it?
There are a few things that cause compilers to fall over such code:
* out of memory (heap/stack)
* overflow of internal buffer (eg object file size, constant pool)
* compiler bug (the chances of finding a bug increase non-linearly with
function size; this particularly applies to dumb generated code)
> What changes can I apply to the _code_ to reduce compile time/make it
> possible to compile the file?
* Split the function into smaller ones
Most compilers optimize a function at a time. Since they use algorithms
with complexity order N^2 or even N^3, a smaller function will be compiled
quicker.
* Generate switch statements with fewer cases (same as above)
* Generate fewer if statements
Dense control flow will slow down dataflow analysis.
* Generate less dead code
Eventhough the compiler can/will optimize it away, it might slow it
down or inadvertently block other optimizations.
* Use local variables
Global variables generate much more (intermediate) code. It is often
best to copy global variables on function entry, and write them back
before returning. This reduces the strain on alias analysis a lot,
and generates better code.
> case 0x00001798: oldPC = PC; { ; { instruction_counter++; { ; { {
> ; { barrel_shifter_operand2_bus = rot_imm(0 , 0 , 0 ); } ; } ; { ; {
> R[0x3] = barrel_shifter_operand2_bus; if (& R[0x3] == &R[15]) R[0x3]
> -=4; } ; } ; } ; } ; } ; } ; cycle++; PC += 4; if (PC != (oldPC + 4))
> break;
I suppose PC is #defined as R[15]? Then I don't understand why you
do the PC increment at the start, and skip the weird PC correction
step in the first if statement. Note that the compiler will be unable
to optimize the redundant PC != (oldPC +4) check due to the call to
rot_imm (unless you define rot_imm in the same file _and_ are brave
enough to compile with O3...). And why not write:
if (PC != oldPC) break; PC += 4;
Also, since most instructions take a single cycle, you could increment
the cycle counter with the cycle count minus one. This normally means
you don't have to increment it. When the real cycle count is needed,
simply add the instruction count.
Wilco
-----------------------------------------------------------------------
Wilco Dijkstra ARM Ltd
Software Engineer Fulbourn Road
Wilco.Dijkstra@arm.com Cherry Hinton, CB1 9JN
Phone: +44 1223 400 518 Cambridge, UK
Return to the
comp.compilers page.
Search the
comp.compilers archives again.