An `std::vector<T>::reverse_iterator` stores the
`std::vector<T>::iterator` which points to the (forwards-ordered)
*following* item. Thus while `vec.rbegin()` dereferences to the final
item of `vec`, the iterator it wraps (`vec.rbegin().base()`) is equal to
`vec.end()`.
In the remove case here, we advance `it` (backwards), erasing the item
we just advanced past by grabbing its (pre-increment) base
forward-iterator and subtracting 1.
The iterator maths here is obviously all OK, but the forward-iterator
that `it` wraps post-increment actually points to the item we just
removed. That iterator was invalidated by the `erase()` call.
That this works anyway is (AFAICT) some combination of luck and/or
promises that aren't part of the C++ spec, but MSVC's debug iterator
support picks this up.
`erase()` returns the new iterator that follows the item just erased,
which happens to be the exact one we want our reverse-iterator to wrap
for the next loop; we get a fresh iterator to the same base, now without
the preceding item.
Before this commit, in a process like:
process $proc$bug.v:8$3
assign $foo \bar
switch \sel
case 1'1
assign $foo 1'1
assign $foo 1'1
case
assign $foo 1'0
end
end
both of the "assign $foo 1'1" would incorrectly be removed.
Fixes#1243.
This can pave the way for further transformations by exposing
identities that were previously hidden in a process to any pass that
uses SigMap. Indeed, this commit removes some ad-hoc logic from
proc_init that appears to have been tailored to the output of
genrtlil in favor of using `SigMap.apply()`. (This removal is not
optional, as the ad-hoc logic cannot cope with the result of running
proc_prune; a similar issue was fixed in proc_arst.)
The proc_prune pass is similar in nature to proc_rmdead pass: while
proc_rmdead removes branches that never become active because another
branch preempts it, proc_prune removes assignments that never become
active because another assignment preempts them.
Genrtlil contains logic similar to the proc_prune pass, but their
purpose is different: genrtlil has to prune assignments to adapt
the semantics of blocking assignments in HDLs (latest assignment
wins) to semantics of assignments in RTLIL processes (assignment in
the most specific case wins). On the other hand proc_prune is
a general purpose RTLIL simplification that benefits all frontends,
even those not using the Yosys AST library.
The proc_prune pass is added to the proc script after proc_rmdead,
since it gives better results with fewer branches.
Charlotte
Marcelina Kościelnicka
whitequark
Eddie Hung
Jean-François Nguyen