bug#46502: 28.0.50; [feature/native-comp] (d3a399dd) native-comp bootstrap failure

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> One of the possibility is always the inlining (where we either inline
>> the source code or the bytecode depending on whether the function to be
>> inlined has already been byte-compiled).
> That's what it looks like. Are we supposed to fold constants in both cases?

Not sure what you mean by "fold constants", but when inlining byte-code
we "disassemble" the byte code into LAP code (which is just like byte
code but represented as a Lisp list with symbols) an then splice that
into the LAP code of the caller.  So it tends to lead to slightly less
good code because we don't get to apply the source-level optimizer to
the combination of the caller and callee (but we still do apply the
bytecode (so called "peephole") optimizer).

For example, Mattias's new constant propagation code and the resulting
constant folding opportunities doesn't work as well.

We could change the way `defsubst` works so we *always* inline the
source code[1] (but at the cost of having to keep the source code
around).  But it doesn't seem worth it: we already have `cl-defsubst`
which does just that, and we also have `define-inline` which can do an
even better job.

>> Can you try the patch below to see if it makes a difference?
> It does, no difference with the patch.

So the effect of the patch is that the build is now (more) reproducible?


        Stefan


[1] except when cross-inlining from different dialects, of course.