Hi,
On 2023-12-15 22:19:56 -0500, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > On Sat, Dec 16, 2023 at 3:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Thomas Munro <thomas.munro@gmail.com> writes:
> >>> FYI, it looks like there is a big jump in CPU time to compile preproc.c at -O2:
> >>> clang15: ~16s
> >>> clang16: ~211s
> >>> clang17: ~233s
Is this with non-assert clangs? Because I see times that seem smaller by more
than what can be explained by hardware differences:
preproc.c:
17 10.270s
16 9.685s
15 8.300s
gram.c:
17 1.936s
16 2.131s
15 2.161s
That's still bad, but a far cry away from 233s.
> Huh. There's not that many more productions in the ecpg grammar
> than the core, so it doesn't seem likely that this is purely a
> size-of-file issue. I'd bet on there being something that clang
> doesn't do well about the (very stylized) C code being generated
> within the grammar productions.
>
> We actually noticed this or a closely-related problem before [1]
> and briefly discussed the possibility of rearranging the generated
> code to make it less indigestible to clang. But there was no concrete
> idea about what to do specifically, and the thread slid off the radar
> screen.
One interest aspect might be that preproc.c ends up with ~33% more states than
gram.c
gram.c:
#define YYLAST 116587
preproc.c:
#define YYLAST 155495
Greetings,
Andres Freund