Possible compiler bug: continue is skipped after or-condition

[Andrew Dinn]

On 17/02/2020 14:45, B. Blaser wrote:
> I believe the current behavior to skip line 7, as you described below,
> looks correct.
> However, we could probably generate something closer to the source
> code when enabling debug with "-g" as we did for lambda factorization
> [1], for example.
> Maybe someone else could comment on this but I'm not sure the gain
> would worth the pain as you could certainly put a breakpoint on line
> 5.
> 
> Any feedback is welcome,
Feedback, as requested:

I'm a bit surprised that the current code 'optimizes' the bytecode by
eliding indirect (i.e. multi-hop) jumps. That's pointless as regards
execute time performance given that we have a JIT that will do that
elision for you when it really matters. It does, however, save some
space, which is perhaps why it was introduced. Maybe it dates back to a
time before there were JITs . . . ?

Anyway, historical speculation aside, this implementation detail belies,
for a second reason that bypasses the taint of premature optimization,
what I see as a useful guiding principle when it comes to bytecode
generation: leaving the bytecode as close to original source code as is
possible.

What's the reason, you ask <eh?___ah_thank_you_for_asking/>? Simply that
following that principle makes life easier for bytecode transformers. It
leaves them better able to identify aspects of the source code that
might determine the specific details of what transform to apply. That
same benefit is most obviously manifest in the more coherent rendering
of line numbers provided when this elision is omitted.

However, that said ... I'm not sure that "generate something closer to
the source code when enabling debug" is such a good idea. Two bytecode
variants? Eek! I suggest that this would to invite potential breakage
for quite some few existing bytecode transformers and perhaps trip up
one or two new ones.

Reverting the jump elision wholesale would be better but, by the same
token, I would also hesitate to apply that reversion. The line number
issue is a real problem but we seem to have lived with it for a long
time without any really severe consequences. In sum, it's not really
broke so best not to fix it and risk breaking something else.

Your mileage (or, indeed, your bytecode) may vary,

regards,


Andrew Dinn
-----------