You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When constant-folding a range/flipflop construct, the op_next threading
of peephole optimisation caused multiple ops in the construct to have
a null op_next, because the final (and top-level) op in the construct
is a null op. This meant that simple restoration of the top-level
op's op_next after execution wouldn't get it back into a fit state
to be composed with other ops. In the event that the range construct
couldn't be constant-folded this made it compile to a broken optree.
If it couldn't be constant-folded but could actually be executed, for
example because it generated a warning, this meant the brokenness would
be encountered at runtime. Execution would stop after the range op,
because of the null op_next.
To avoid this, temporarily mark the null op as a custom op during the
peephole optimisation that supports the execution for constant-folding.
This prevents it being op_next-threaded out, so simple op_next restoring
then works. If the constant-folding is aborted, it compiles to an
operational optree. However, the suppression of duplicate peephole
optimisation means that the null op is never ultimately threaded out
as it should be. For the time being, this stands as a cost of failed
constant-folding of range constructs.
Fixes [perl #130639].
0 commit comments