Martin Kinkelin

Argh, looks like failing LLD assertions on Windows now also surface on Win64 with the newer Azure Windows image (and VS 2022). It's a different assertion than the spurious Win32...

I guess this is solely because the latest CI builds feature enabled assertions, i.e., nothing new.

So you're using AST-based PGO; it would be interesting to have a comparison with LLVM-intrinsic IR-based PGO, both in terms of build/profiling time (+ profile file size) and final runtime...

At least one unhandled statement is also encountered when compiling the frontend itself with AST-based PGO (with a host compiler with enabled assertions); e.g., in #3980 tests.

Thx for the input Rainer - yeah a GC wrapper sounds much simpler and more worthwhile, and would also avoid having to adjust the GC2Stack pass (as people would probably...

I'd have to look more deeply into what's required - AFAIK, emitting everything that could contain a pointer to GC-allocated memory into an extra section, for both regular and TLS...

I'd have to check it, but I assume the scope-`pragma(inline)` is simply forwarded to all nested functions/lambdas (and so a frontend thing). I find it baffling that `foo3.bar` is inlined;...

But it doesn't do it for the lambda in `foo1`, although the IR for them is almost identical when making `foo3.bar` `static` (no context pointer); the only difference I've spotted...

> Any function - nested or not - being inlined or not should be done when the compiler sees fit unless I have marked it explicitly one way or another....

This was deprecated in v2.096 (https://dlang.org/changelog/2.096.0.html#deprecate_dualcontext).