Many improvements to smartmatching and given/when

[vrurg]

• Junctions are now welcome on RHS and as when topic
• when now uses optimized code unless the topic is a Junction. Falls back to ACCEPTS+Bool in the latter case.
• smartmatch optimization is now more elaborate about its arguments. It implicitly Bool-ifies ACCEPTS return value unless its LHS is a regex or negation is to be done.
• more optimizations for literal and type matching

Overall, with this PR it must not be a problem if ACCEPTS gets autothreaded and results in a junctionized return. Either it will be collapsed with boolification where smartmatch semantics is expected, or junctionized outcome of a regex match is expected.

[vrurg]

PR resolves Raku/problem-solving#297. Fixes #2676 and, perhaps, a few more issues (yet to be investigated).

[vrurg]

A couple of implementation notes.

To get junctions work as topics with when I had to add additional istype check into the optimized code @MasterDuke17 produced to fall back to ACCEPTS when appropriate. Then I compared this branch with 2021.10 release. And it seems that the branch is even somewhat faster – likely because of all the MoarVM optimizations done since the release.

As I have noticed in the commit comment, Range will not work with custom user-provided cmp operator. This was always the case and I don't feel ok about trying to fix it as it would require looking for client's context and locating the operator proto in there. Yet, considering that we also always had Range.ACCEPTS with Mu-typed topic, I decided there is no loss in keeping it this way but adding the code for operator lookup as otherwise it makes no sense. If this approach is considered redundant, not only the corresponding candidate could be removed, but there is a chance for slight optimization of the multi-dispatch by removing Junction candidate and providing Range with own proto method ACCEPTS.

[vrurg]

Turning this into draft because there is some more work in progress on optimizing when and fixing cases where class defines custom ACCEPTS.

[vrurg]

I think I'm done with this. The PR passes spectests, including the additions from Raku/roast#774. Aside of the fix for junctions on LHS and as when topic, I couldn't resist optimizing some most common cases. The optimization tries to cover cases, where compile time values are known, sometimes replacing a smartmatch with a plain boolean constant. For example, this would happen for:

sub foo(--> Num) { ... }
if foo() ~~ Numeric { ... }

Note that it means no call to foo() would ever take place.

Overall, the basic principles of optimization I tried to follow were:

• where possible, get rid of routine calls by replacing their code with nqp ops
• reduce allocations by unwrapping instantiation ASTs and pulling out any constant data available
• calculate op outcomes at compile time where possible

Because the above involves a lot of analyzing of value ASTs, I added a new class Operand to the optimizer code which does all this work.

Unfortunately, I barely can provide many benchmark results as dispatching is seemingly taking so good care of the cases I tried, that sometimes a test loop happens to be even faster, than a base-line loop with no smartmatch in it. But at least in one case of smartmatching against pairs I did observe a speedup of 49%:

constant COUNT=1_000_000;
my $base = 0;
my $s = now;
for ^COUNT {
    my $v = $foo.bar1 === True;
}
$base = now - $s;

note "Base: ", $base;

my $total = 0;
$s = now;
for ^COUNT {
    my $v = $foo ~~ :bar1;
}
$total = now - $s;

note "Total: ", $total, ", actual: ", $total - $base;

[vrurg]

Update. With JVM fixed I've benchmarked it too. 88% for pair, 92% for $v ~~ Num.