I have attached a patch to master that adds "define-inline-pure-subr"
to inline.el and converts all defined functions marked as pure to be
inlined.  The approach in the patch reflects my intention to include
this feature in an external package.  I'm sure the maintainers would
modify the source of the pure functions to use it directly, if they
were interested in the feature.

This version bootstraps and "make check" succeeds at least.  It also
works as intended:
(require 'byte-opt)
(require 'inline)
(macroexpand-all '(+ 5 7)) => 12
(macroexpand-all '(cl-typep 5 'integer)) => t

So, the user can see the effects of "compile-time" evaluation of
constant expressions in the source code instead of disassembling the
generated byte-code.

Lynn

On Fri, May 12, 2023 at 9:02 PM Lynn Winebarger <owinebar@gmail.com> wrote:
>
> I adapted the define-inline function to allow redefinition of existing
> function names to be an inlining version that will evaluate constant
> arguments during macroexpand-all, without involvement of the compiler.
> The code is below this message.
>
> For example, for a truly pure function
> (define-inline-pure-subr + (&rest numbers-or-markers))
>
> It can also be used for not-quite-pure functions that may still be
> desirable to evaluate at compile-time using an explicit inline-*
> variant:
> (define-inline-pure-subr format (string &rest objects) inline-format)
>
> There is code following the definition of define-inline-pure-subr to
> find all function symbols declared pure and perform the redefinition
> on them.  Emacs doesn't immediately fail when I run it, but I haven't
> recompiled emacs with the code added to inline.el.
>
> At the bottom is a variant of define-inline, define-inline-pure, that
> replicates define-inline, except it evaluates the function call during
> macroexpansion if all arguments expand to constant expressions.  I
> have not tested it at all.
>
> The envisioned use case is dispatching macros to generic functions to
> get specialization at compile-time.  Presumably the byte-compiler's
> optimization code might be slightly simplified as well.
>
> Lynn