Re: GCC does not cope with my code

Wilco Dijkstra <Wilco.Dijkstra@arm.com>
28 May 2000 21:07:11 -0400

          From comp.compilers

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)
| List of all articles for this month |

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.