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

[Michael Welsh Duggan <mwd@md5i.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Ping?

Sorry.  Wasn't able to trigger a failure on Friday.  (I tried.)  And
I've had other things to do on the weekend.  I'll be trying again Monday
morning.

>
> Stefan Monnier [2021-02-20 12:12:54] wrote:
>
>>>> 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.
>

-- 
Michael Welsh Duggan
(md5i@md5i.com)