As the removed comment suggests, this is dubious and RTLMeter suggests
it makes no measurable difference on average (some designs improve, some
regress small amounts, on average ~1.0x)
Prep for further fixes that will remove the pre ranking.
Prep for fixing test added in #7913.
This is a large scale no functional change refactor, however, MT output
is perturbed as tied scores will be broken differently due to ordering
changes (still deterministic).
Split multi-threaded scheduling out of the monolithic
V3OrderParallel.cpp, into relatively independent parts, simplify the
data structures, and drop redundant or unused code.
New translation units:
- V3OrderMTaskGraph.h/.cpp: OrderMTaskGraph, the graph of LogicMTask
vertices and MTaskEdge edges. LogicMTask and MTaskEdge no longer
depend on the coarsening algorithm's merge candidate types;
per-algorithm auxiliary data is attached externally via the vertex and
edge user pointers.
- V3OrderMTaskFixHazards.cpp: data hazard fixup, was FixDataHazards.
- V3OrderMTaskContraction.cpp: graph coarsening, was Partitioner
together with PropagateCp and the merge candidate types.
- V3OrderParallel.cpp: now just the partitioning driver and ExecMTask
graph construction.
Data structure changes:
- Delete V3Scoreboard.h/.cpp. The generic template had a single user, now
a file-local MergeCandidateScoreboard in V3OrderMTaskContraction.cpp.
- Merge candidates are now MergeCandidate/SiblingMC/EdgeMC, distinguished
by a bit in the candidate id rather than by a vtable, and allocated by
the scoreboard, which owns their lifetime. This removes the multiple
inheritance previously used by MTaskEdge.
Move `hashGraphDebug` which prints the hash of a graph's shape for debugging
to generic `V3Graph::hashGraphDebug`.
Removed (can be added back later):
- Unnecesasry self tests that force special data stucture requirements.
- Per stage --stats output under --debug. (Final figures still reported.)
- Various debug dumps
The REPLACE_SHIFTL_SHIFTL and REPLACE_SHIFTR_SHIFTR peephole optimizations
fold '(a << b) << c' into 'a << (b + c)' (and likewise for '>>'), but computed
'b + c' in the width of the shift-amount operand. When 'b + c' overflows that
width it wraps around, producing a too-small shift amount and a wrong result.
Compute the sum one bit wider than the amounts so it cannot overflow.
Fixes#7955
Nick Brereton
Geza Lore
David Garau
Yilou Wang
Aisha
Josep Sans
Marco Bartoli
BRDR LIFE
Artur Bieniek
Gilberto Abram
spomatasmd
Wilson Snyder
Bartosz Skorowski
github action
Jakub Michalski
Kornel Uriasz
Igor Zaworski
Pawel Klopotek
Philip Axer
Patrick Creighton
Mateusz Gancarz
Adam Kostrzewski
Andrii