From 8f22d20012ecdb8737e61beb4fa0480ab18f222d Mon Sep 17 00:00:00 2001 From: Kaz Kylheku Date: Tue, 13 Sep 2022 23:55:45 -0700 Subject: compiler: bugfixes in dead code elimination * stdlib/optimize (basic-blocks ling-graph): I'm reverting an old design decision here. The decision is this: the basic block of a close instruction points to the first basic block of the closure as its next block, but that next block does not point back: it doesn't list the close instruction's basic block among the rlinks. The idea was that the close instruction doesn't jump to that block, and so it shouldn't be linked to it. However, the next link was set purely so that the graph is connected. Unfortunately, the inconsistency in the graph structure which this causes is a problem in the elim-dead-code method. A situation arises when that first basic block after the close is removed. Because pit has an empty rlinks list, the block remains listed as the next block of the close block, even though it is removed from the master list of blocks. (basic-blocks check-bypass-empty): Fix one forgotten detail in this function: the block being deleted must be removed from the rlinks list of the next block. --- stdlib/optimize.tl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/stdlib/optimize.tl b/stdlib/optimize.tl index 8e1e8182..914df5b3 100644 --- a/stdlib/optimize.tl +++ b/stdlib/optimize.tl @@ -135,8 +135,7 @@ (set bl.links (list [bb.hash jlabel]))) ((close @nil @nil @nil @jlabel . @nil) (set bl.links (list [bb.hash jlabel]) - bl.next nxbl - link-next nil)) + bl.next nxbl)) ((swtch @nil . @jlabels) (set bl.links [mapcar bb.hash (uniq jlabels)] link-next nil)) @@ -502,6 +501,7 @@ (defmeth basic-blocks check-bypass-empty (bb bl nx) (unless (cdr bl.insns) + (upd nx.rlinks (remq bl)) (each ((pb bl.rlinks)) (if (eq pb.next bl) (set pb.next nx)) -- cgit v1.2.3