Re: Clang optimiser vs preproc.c

Hi,

On 2023-12-15 22:19:56 -0500, Tom Lane wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > On Sat, Dec 16, 2023 at 3:44 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Thomas Munro <thomas(dot)munro(at)gmail(dot)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