Thanks.
There was a thread in January starting at
https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01005.html that gets at one scenario. At least in pre-10 versions in my experience, Windows has not dealt well with large numbers of files in a single directory, at least if it's on a network drive. There's some super-linear behavior just listing the contents of a directory that makes having more than, say, a thousand files in a directory impractical. That makes packaging emacs with all files on the system load path precompiled inadvisable. If you add any significant number of pre-compiled site-lisp libraries (eg a local elpa mirror), it will get worse.
Aside from explicit interprocedural optimization, is it possible libgccjit would lay out the code in a more optimal way in terms of memory locality?
If the only concern for semantic safety with -O3 is the redefinability of all symbols, that's already the case for emacs lisp primitives implemented in C. It should be similar to putting the code into a let block with all defined functions bound in the block, then setting the global definitions to the locally defined versions, except for any variations in forms with semantics that depend on whether they appear at top-level or in a lexical scope. It might be interesting to extend the language with a form that makes the unsafe optimizations safe with respect to the compilation unit.