compiler: another late peephole pattern.

There are six hits for this in stdlib, two of them in
optimize.tl itself. The situation is like:

  label1
    (instruction ...)
    (jmp label3)

  label2
    (instruction ...)

  label3

where (instruction ...) is identical in both places.
label1 and label2 are functionally identical blocks, which
means that the pattern can be rewritten as:

  label1
  label2
    (instruction ...)

  label3

When the label1 path is taken it's faster due to the
elimination of the jmp, and code size is reduced by two
instructions.

This pattern may possibly the result of an imperfection in the
design of the basic-blocks method merge-jump-thunks.
The label1 and label2 blocks are functionally identical.
But merge-jump-thunks looks strictly for blocks that end in a
jmp instruction. It's possible that there was a jmp
instruction and the end of the label2 block, which got
eliminated before merge-jump-thunks, which is done late, just
before late-peephole.

* stdlib/optimize.tl (basic-blocks late-peephole): New rule
for the above pattern.

1 files changed, 12 insertions, 0 deletions

diff --git a/stdlib/optimize.tl b/stdlib/optimize.tl
index 52b39182..57eca186 100644
--- a/stdlib/optimize.tl
+++ b/stdlib/optimize.tl
@@ -625,6 +625,18 @@
        ,lab2
        (end (t ,ty))
        ,*rest))
+    ((@(symbolp @lab1)
+      @(consp @insn)
+      (jmp @lab3)
+      @(symbolp @lab2)
+      @insn
+      @(symbolp @lab3)
+      . @rest)
+     ^(,lab1
+       ,lab2
+       ,insn
+       ,lab3
+       ,*rest))
     (@else else)))
 
 (defun rewrite (fun list)