This commit adds a new run_pass() method to the RTLIL::Design class,
providing a convenient API for executing Yosys passes programmatically.
This is particularly useful for PyYosys users who want to run passes
on a design object without needing to manually construct Pass::call()
invocations. The method wraps Pass::call() with appropriate logging
to maintain consistency with command-line pass execution.
Example usage (from Python):
design = ys.Design()
# ... build or load design ...
design.run_pass("hierarchy")
design.run_pass("proc")
design.run_pass("opt")
Changes:
- kernel/rtlil.h: Add run_pass() method declaration
- kernel/rtlil.cc: Implement run_pass() method
- tests/unit/kernel/test_design_run_pass.cc: Add unit tests
I'm not sure why but this is actually faster than existing `opt_merge` even with
YOSYS_MAX_THREADS=1, for the jpeg synthesis test. 16.0s before, 15.5s after for
end-to-end synthesis.
Now that we're not refcounting `IdString`, it can use the default move constructor.
This lets us make `IdString` a POD type so it can be passed in registers
in the standard C++ ABI.
When IdString refcounting was expensive, it made sense to pass it by const reference
instead of by value, to avoid refcount churn. Now that IdString is not refcounted,
it's slightly more efficient to pass it by value.
When something calls `IdString::c_str()` on an autoidx ID, we need to cache the
full string in a thread-safe way. If we need to allocate an entry in some data
structure to do that, it's difficult to do in a thread-safe no-performance-hazard way.
So instead, store the cached string pointer in the same hashtable as the prefix
pointer.
We could make it safe to increment autoidx during multithreaded passes, but that's
actually undesirable because it would lead to nondeterminism. If/when we need new
IDs during parallel passes, we'll have to figure out how to allocate them in a
deterministic way, and that will depend on the details of what the pass does.
So don't try to tackle that now.
Refcounting is hardly used at all so this option is not that useful.
We might want to have a different option that disables GC if that becomes
a performance issue, but that should be a different option.
