[Bug c/66682] New: Lots of macro expansion, very slow compilation

[cr88192 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682

Bug ID: 66682
   Summary: Lots of macro expansion, very slow compilation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cr88192 at gmail dot com
  Target Milestone: ---

Created attachment 35857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35857&action=edit
stand-alone code which demonstrates issue

Some code with large amounts of macro-expansion (and producing a large number
of small functions) takes an inordinate amount of time to compile with GCC (the
example, around 3 minutes with 4.5.2 and 4.5.3, and 8 minutes with 4.8.2).

However, with several other compilers, the same code compiles within a few
seconds.

The code fragment represents part of a native function-call dispatcher
mechanism from an interpreter (a lot of the interpreter is heavily macro'ed
like this, using macros to produce type-specialized versions of operations).

[Bug c/66682] Lots of macro expansion, very slow compilation

[cr88192 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682

cr88192 at gmail dot com changed:

   What|Removed |Added

Version|unknown |4.8.2

--- Comment #3 from cr88192 at gmail dot com ---
(In reply to Manuel López-Ibáñez from comment #2)
> Note that this code is not really "stand-alone": See
> https://gcc.gnu.org/bugs/#need

Testing: -ftrack-macro-expansion=0
  Linux (4.8.2): 6m41s

Windows (4.5.2 and 4.5.3):
  cc1.exe: error: unrecognized command line option "-ftrack-macro-expansion=0"


As for standalone:
It compiles by itself (doesn't need external headers or other things).

Command-line:
  time gcc -o natcall_lnx.elf natcall_sa.c

Compiler output:
  no messages normally.


Temporaries files: generally too big to upload:
  5MB for the .i file;
 14MB for the .s file;
  3MB for the .o file.

Noticed: both GCC and MSVC seem to generate approximately the same-sized output
files (so, it doesn't seem the amount of data is all that much different).


The generated output seems to work correctly, but it is just rather slow.
For contrast:
 MSVC compiles the same code in about 2 seconds;
 My own experimental compiler does it in 6 seconds
   ( It targets the VM the code is from )

It seems like there may be "something wrong" for it to be so slow.

More so, rebuilding something on Linux taking a long time (around an hour or
so) is a bit questionable, when MSVC on Windows does the same thing in a matter
of seconds.

[Bug c/66682] Lots of macro expansion, very slow compilation

[cr88192 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682

--- Comment #7 from Brendan G Bohannon  ---
(In reply to Mikhail Maltsev from comment #6)
> Created attachment 35859 [details]
> Sampling profile of cc1
> 
> It's hard to say what's wrong here (why do we perform so many lookups in
> mem_attrs hash table? collisions?) without looking further.

The code in question creates about 7k internal functions, which could be a
factor?


The VM it is from, in general, creates large numbers of one-off functions via
macros. Most of this is because the interpreter structure is built around
structs and calls through function-pointers (with the bytecode decoded into
"Traces", AKA: "Extended Basic Blocks", which are executed via unrolled loops
of calls through function-pointers, in turn driven by a top-level trampoline
loop). Functions for basic operations are expanded out in terms of combinations
of parameter and data types (in turn, the functions are fairly specialized).

This structure is used as it gives fairly good performance for a reasonably
portable plain-C interpreter.