Add per-object origin tracking (vOrigins) to Gia_Man_t

[robtaylor]

Summary

This adds lightweight per-object origin tracking to Gia_Man_t, enabling the Yosys abc9 flow to preserve \src (source-location) attributes on LUT cells through ABC's optimization passes.

Motivation

We are working on preserving \src (source-location) attributes through the Yosys abc9 synthesis flow. The approach uses the XAIGER "y" extension to pass an object-to-source mapping through ABC — Yosys writes the mapping on &read, ABC preserves it during optimization, and Yosys reads it back on &write to annotate the resulting LUT cells.

We initially prototyped a &verify -y approach that uses combinational equivalence checking to reconstruct the mapping after optimization, but this only achieves 17-57% coverage on non-trivial designs and doesn't work for sequential circuits. This PR takes a different approach — propagating origins during optimization — which achieves ~100% coverage.

Approach

Add a single Vec_Int_t *vOrigins vector to Gia_Man_t that maps each object to its "origin" input-side object ID:

• Initialized from the "y" extension on &read (AIGER reader)
• Propagated through all dup/conversion/optimization passes and all major ABC9 engines
• Written to "y" extension on &write (AIGER writer)
• Heuristic: when creating AND/XOR/MUX via structural hashing, inherit the origin with the lowest valid ID from the parents

Three propagation helpers handle different transformation patterns:

• Gia_ManOriginsDup() — for standard dup operations that use the Value field for old→new mapping
• Gia_ManOriginsDupVec() — for functions using Vec_Int_t copy vectors (e.g., Jf/Lf mappers)
• Gia_ManOriginsAfterRoundTrip() — for GIA→AIG→GIA round-trips (&dc2, &dch, &synch2) where per-object data is lost; recovers origins via CI/CO correspondence + top-down fanin propagation

Engine Coverage

Origins are propagated through all major ABC9 engines:

Engine	Function(s)	Propagation method
&dc2	Gia_ManCompress2	Round-trip recovery
&dch	Gia_ManPerformDch	Round-trip recovery
&if	IF mapper + SopBalance/DsdBalance	iCopy correspondence
&syn2	Jf/Lf mappers + sub-operations	OriginsDupVec
&synch2	Jf/Lf mappers + AigSynch2Choices	OriginsDupVec + round-trip recovery
&sweep	FraigReduceGia, DupWithBoxes	OriginsDup
&scorr	Gia_ManCorrReduce	OriginsDup
&mfs	Gia_ManInsertMfs	Custom via vMfs2Old/vMfs2Gia
&nf	Nf_ManDeriveMapping	No changes needed (returns same GIA)

Performance

Benchmarked on picorv32 (4-LUT mapping via abc9):

Metric	Without origins	With origins	Overhead
Wall-clock time	~3.0s	~3.02s	~0.6%
Peak memory	~48MB	~49.5MB	~3%
LUT count	identical	identical	0%

The overhead is negligible — approximately 4 bytes per GIA object for the vOrigins vector, with O(1) propagation per node creation.

Coverage

With this change, \src retention on LUT cells after abc9 mapping improves from 17-57% to 100% on all tested designs (simple combinational, Amaranth-style, and larger multi-output designs with 54 LUTs).

Files changed

File	Change
src/aig/gia/gia.h	Add vOrigins field + inline accessors + helper declarations
src/aig/gia/giaMan.c	Free vOrigins in Gia_ManStop
src/aig/gia/giaAiger.c	Read/write vOrigins via "y" extension
src/aig/gia/giaDup.c	Gia_ManOriginsDup + Gia_ManOriginsDupVec + Gia_ManOriginsAfterRoundTrip; instrument all Gia_ManDup* variants
src/aig/gia/giaHash.c	Propagate origins in Gia_ManHashAnd, Gia_ManHashXorReal, Gia_ManHashMuxReal, Gia_ManRehash
src/aig/gia/giaAig.c	Recover origins after AIG round-trips in Gia_ManCompress2 (&dc2) and Gia_ManPerformDch (&dch)
src/aig/gia/giaIf.c	Propagate through IF mapper via iCopy + SopBalance/DsdBalance
src/aig/gia/giaJf.c	Propagate in Jf_ManDeriveGia and Jf_ManDeriveMappingGia via OriginsDupVec
src/aig/gia/giaLf.c	Propagate in Lf_ManDeriveMappingCoarse and Lf_ManDeriveMappingGia
src/aig/gia/giaMfs.c	Propagate in Gia_ManInsertMfs via MFS ID correspondence
src/aig/gia/giaScript.c	Round-trip recovery in Gia_ManAigSynch2Choices
src/aig/gia/giaSweep.c	Propagate in Gia_ManFraigReduceGia and Gia_ManDupWithBoxes
src/aig/gia/giaEquiv.c	Propagate in Gia_ManEquivReduce and Gia_ManEquivToChoices
src/aig/gia/giaMuxes.c	Propagate in Gia_ManDupMuxes/Gia_ManDupNoMuxes
src/aig/gia/giaTim.c	Propagate in Gia_ManDupNormalize/Gia_ManDupUnnormalize/Gia_ManDupCollapse
src/aig/gia/giaBalAig.c	Propagate in balance operations
src/opt/dau/dauGia.c	Propagate in Dsm_ManDeriveGia
src/proof/cec/cecCorr.c	Propagate in Gia_ManCorrReduce

Context

This is part of work on YosysHQ/yosys#5712 to improve \src attribute retention through the abc9 flow.

cc @alanminko @Ravenslofty — would appreciate your thoughts on this approach.

[robtaylor]

Adding @alanminko's response here from email for my context:

It looks like your implementation is quite clean and has low resource usage. Currently it supports basic AIG manipulations (copy, balancing, etc). The next step is to propagate it into the engines, which manipulate XAIGs (&dc2, &if, &nf, &mfs, &syn2, &dch, &synch2, &sweep, &scorr, etc). It appears to be a lot of work but perhaps it can be quickly done using AI agents.

Glad this method works for mapping RTL code into the resulting AIG nodes (as well gates and LUTs after mapping). It also does not have the overhead of equivalence checking, required by the previous approach.

I'm now working on adding propagation into the engines, as advised.

[robtaylor]

Following up on Alan's feedback — this new commit propagates vOrigins through all the major ABC9 engines:

Engines now instrumented:

Engine	Function(s)	Propagation method
&dc2	Gia_ManCompress2	Round-trip recovery (already in first commit)
&dch	Gia_ManPerformDch	Round-trip recovery (already in first commit)
&if	Gia_ManPerformSopBalance, Gia_ManPerformDsdBalance	iCopy correspondence
&syn2	Jf/Lf mappers + sub-operations	OriginsDupVec (for vCopies-based mappers)
&synch2	Jf/Lf mappers + Gia_ManAigSynch2Choices	OriginsDupVec + round-trip recovery
&sweep	Gia_ManFraigReduceGia, Gia_ManDupWithBoxes	OriginsDup (Value field)
&scorr	Gia_ManCorrReduce	OriginsDup (Value field)
&mfs	Gia_ManInsertMfs	Custom via vMfs2Old/vMfs2Gia
&nf	Nf_ManDeriveMapping	No changes needed (returns same GIA)

New helper added: Gia_ManOriginsDupVec() — like Gia_ManOriginsDup() but for functions that use a Vec_Int_t copy vector (e.g., Jf/Lf mappers) instead of the Value field.

Supporting functions also instrumented: Gia_ManDupCollapse (giaTim.c), Gia_ManEquivToChoices (giaEquiv.c).

Testing: Origins survive through all individual engines and chained pipelines (&dc2; &synch2; &if; &mfs). The change adds 86 lines across 11 files with no new allocations on the hot path.

[Shadlock0133]

can we not with the ai slop?

[robtaylor]

can we not with the ai slop?

would you like to actually check the code first? Already discussed with @alanminko as this is the sort of change where AI helps.

[robtaylor]

Performance Benchmark

Benchmarked origin propagation overhead on i10.aig (2675 ANDs, 257 inputs, 224 outputs) — same circuit with and without origins loaded, 20 iterations each:

Pipeline	No Origins	With Origins	Overhead
&dc2	68.6±0.9ms	70.3±1.0ms	+2.4%
&syn2	25.0±0.7ms	24.5±0.5ms	-1.8%
&synch2	139.8±0.9ms	139.9±1.4ms	+0.1%
&dch	143.6±1.4ms	143.8±1.7ms	+0.1%
&scorr	17.2±0.6ms	17.4±0.8ms	+1.4%
&sweep	26.1±1.1ms	26.3±0.6ms	+0.8%
&if -K 6	39.5±0.9ms	39.4±0.6ms	-0.2%
&dc2; &syn2; &if	89.2±1.6ms	88.1±1.1ms	-1.2%
&dc2; &synch2; &if; &mfs	390.7±1.6ms	393.3±3.6ms	+0.7%

All overhead is within measurement noise (~1%). The full abc9-style pipeline (&dc2; &synch2; &if -K 6; &mfs) shows +0.7% overhead — essentially free.

Methodology: Same circuit loaded with (&r -s file_with_y.aig) and without (&r -s file_no_y.aig) the "y" extension. The only difference is whether vOrigins is allocated and propagated. macOS/ARM64, 20 iterations averaged.

[akashlevy]

@robtaylor Does this support multiple origins per object? Or just one?

[alanminko]

Thank you for keeping me in the loop. One thing observed is that following comment is not correct in all cases: "&nf -> No changes needed (returns same GIA)". Please note that all technology mappers (&if, &lf, &jf, &nf), when applied to an AIG with structural choices, derived by &dch or &synch2, return a different AIG after mapping. Of course it is possible to not use structural choices, but this leads to area/delay degradation on most of the designs.

[robtaylor]

@akashlevy Single origin per object — each GIA object maps to one ancestor in the original AIG. This keeps the tracking lightweight (one int per object, zero allocations on the hot path).

Multi-source attribution is better handled at the Yosys layer: when mapping LUTs back to RTL cells, a single LUT may cover multiple original AIG objects. Yosys already has infrastructure for merging \src attributes (e.g., \src "foo.v:10|bar.v:20"), so it can union the \src values of all original objects that a LUT's origin chain touches. ABC just needs to provide the single best origin per object as an anchor for that lookup.

[robtaylor]

@alanminko Thank you for the feedback. You're right that all technology mappers can return a different AIG when structural choices are present.

Looking at the current code, I believe &nf is actually covered but my PR comment was misleading — here's why:

• &jf and &lf have two paths: a "same GIA" path (Jf_ManDeriveMapping, Lf_ManDeriveMapping) and a "new GIA" path (Jf_ManDeriveGia, Jf_ManDeriveMappingGia, Lf_ManDeriveMappingGia). The "new GIA" paths are the ones that needed Gia_ManOriginsDupVec — and they have it.
• &nf's Nf_ManDeriveMapping always returns p->pGia (same pointer) with vCellMapping attached, so vOrigins survives on the same object. The timing/boxes path goes through Gia_ManDupUnnormalize/Gia_ManDupNormalize, both of which already call Gia_ManOriginsDup.
• When choices are present, Nf_ManPerformMappingInt sets fCoarsen = 0 (line 2714), so the coarsening path that creates a different GIA via Gia_ManDupMuxes is skipped.

So I believe the current code is correct, but my summary table was wrong to say "No changes needed (returns same GIA)" without explaining why — it implied I hadn't considered the choices case.

That said, would you prefer a defensive Gia_ManOriginsDup call in Nf_ManPerformMapping for robustness (in case a "new GIA" derive path is added to &nf in the future)? Or have I misunderstood the concern — is there a code path where &nf with choices does produce a different GIA that I'm not seeing?

[robtaylor]

@akashlevy To follow up — the Yosys-side patch that consumes the origin tracking now handles multi-source attribution: for each mapped cell, it collects \src from both the output object's origin and each input object's origin, merging unique values with | (Yosys's multi-source convention).

See the Yosys patch at: https://github.com/robtaylor/yosys/tree/src-retention-y-ext (specifically frontends/aiger/aigerparse.cc and frontends/aiger2/xaiger.cc).

[alanminko]

@robtaylor When one of above mappers is called on AIG with choices derived by &dch or &synch2, it produces a new AIG, annotated with the mapping. It would be good if the origin propagation handled this case.

[robtaylor]

@alanminko Thank you for the clarification. I've traced the code paths for all mappers with structural choices:

Mappers that create a new GIA (origin propagation already added):

• &jf with fPureAig → Jf_ManDeriveGia() — has Gia_ManOriginsDupVec (giaJf.c:1514)
• &jf with fCutMin → Jf_ManDeriveMappingGia() — has Gia_ManOriginsDupVec (giaJf.c:1657)
• &lf with fCutMin → Lf_ManDeriveMappingGia() — has Gia_ManOriginsDupVec (giaLf.c:1907)
• &if → Gia_ManFromIfLogic() / Gia_ManFromIfAig() — has origin propagation via iCopy (giaIf.c)

Mapper that modifies in-place (vOrigins survives on same object):

• &nf → Nf_ManDeriveMapping() returns p->pGia with vCellMapping attached; choices are freed via ABC_FREE(pNew->pReprs/pNexts) but object IDs are unchanged

Is there a specific scenario where &nf (or another mapper) with choices produces a genuinely new GIA object that I'm missing? I want to make sure I'm not overlooking a code path.

[robtaylor]

@alanminko Thank you for pressing on this — I was being too narrow in my earlier analysis. Let me restate more carefully.

For &nf, there are three code paths that can produce a new GIA:

1. Coarsening (fCoarsen=1): Gia_ManDupMuxes → Gia_ManCleanup → Gia_ManDupMarked — all three have Gia_ManOriginsDup calls (giaMuxes.c:143, giaScl.c→giaDup.c:1702)
2. Timing/boxes path: Gia_ManDupUnnormalize and Gia_ManDupNormalize — both have Gia_ManOriginsDup (giaTim.c:424, giaTim.c:189)
3. In-place mapping (choices present, fCoarsen=0): Nf_ManDeriveMapping returns same GIA — vOrigins survives unchanged

More broadly, the Dup functions used across all mappers (DupMuxes, DupMarked, DupNormalize, DupUnnormalize) all propagate origins. And the "new GIA" derive functions in &jf/&lf (Jf_ManDeriveGia, Jf_ManDeriveMappingGia, Lf_ManDeriveMappingGia) have Gia_ManOriginsDupVec calls.

Does this cover the cases you had in mind, or is there a path I'm still missing?

[robtaylor]

Following up — I wrote a static analysis to find all Gia_Man_t* functions that create a new GIA (via Gia_ManStart) from an existing one but don't call Gia_ManOriginsDup or Gia_ManOriginsDupVec. It found 6 gaps in abc9-reachable functions, now fixed:

Function	File	Used by
Gia_ManDupFromBarBufs	giaScript.c	&synch2 with boxes
Gia_ManDupToBarBufs	giaScript.c	&synch2 with boxes
Gia_ManDupUnshuffleInputs	giaTim.c	timing CI reordering
Gia_ManDupMoveLast	giaTim.c	timing CI manipulation
Gia_ManDupHashMapping	giaIf.c	&if -y hash mapping mode
Gia_ManDupUnhashMapping	giaIf.c	&if unhash mapping mode

All 6 use the Value field for old→new object mapping, so adding Gia_ManOriginsDup(pNew, p) before return pNew is the correct fix. The remaining 167 "missing" functions are not in the abc9 pipeline (miters, verification, framing, etc).

Coverage summary: 23 Gia_Man_t* Dup-style functions now propagate origins, covering all paths reachable from the abc9 engines.

[robtaylor]

Latest patch set (6211d3c): Added Gia_ManOriginsDup to 6 additional Dup functions found by static analysis.

The analysis script (gist) finds all Gia_Man_t* functions that:

1. Take a Gia_Man_t* parameter (source GIA)
2. Call Gia_ManStart (create a new GIA)
3. Do not call Gia_ManOriginsDup or Gia_ManOriginsDupVec

It flags 173 functions total, but most are outside the abc9 pipeline (miters, verification, framing, etc). The second script cross-references against abc9 engine entry points to find the 6 that matter. All are now fixed.

Full commit summary:

Commit	Description
e261ac1	Core vOrigins infrastructure (Gia_Man_t field, AIGER "y" read/write, hash propagation)
ace3e2f	Propagation through abc9 engines (&dc2, &dch, &if, &jf, &lf, &nf, &mfs, &syn2, &synch2, &sweep, &scorr)
a213928	Bounds checks for grown GIA objects
8ccd01a	Defensive bounds check in Gia_ObjSetOrigin, propagation in DupWithAttributes
6211d3c	6 additional Dup functions found by static analysis (BarBufs, timing, hash mapping)

[akashlevy]

@akashlevy Single origin per object — each GIA object maps to one ancestor in the original AIG. This keeps the tracking lightweight (one int per object, zero allocations on the hot path).

Multi-source attribution is better handled at the Yosys layer: when mapping LUTs back to RTL cells, a single LUT may cover multiple original AIG objects. Yosys already has infrastructure for merging \src attributes (e.g., \src "foo.v:10|bar.v:20"), so it can union the \src values of all original objects that a LUT's origin chain touches. ABC just needs to provide the single best origin per object as an anchor for that lookup.

Single origin per object implies that the src attribution is lossy. When nodes are merged in abc, you are then forcing one origin only among multiple possibilities. I think this solution is strictly worse than what we had implemented, where we allow for up to N src attributes. Yes, multi-src attribution is more complicated, but it's higher fidelity, and if done correctly, it's only a factor of N more overhead (and any user can feel free to set N=1). Your point about handling multi-src attribution in Yosys is orthogonal to this, because the information loss happens in abc.

[alanminko]

@robtaylor The AIG duplication/reconstruction paths you mentioned are the one I had in mind, so if they are supported, the codes should be fine for handling XAIGs while propagating the origin markers.

[robtaylor]

Ah, it’s one origin per *input* object. Check the Yosys patch for more details.

…

On Mon, 9 Mar 2026 at 18:40, Akash Levy ***@***.***> wrote: *akashlevy* left a comment (berkeley-abc/abc#487) <#487 (comment)> @akashlevy <https://github.com/akashlevy> Single origin per object — each GIA object maps to one ancestor in the original AIG. This keeps the tracking lightweight (one int per object, zero allocations on the hot path). Multi-source attribution is better handled at the Yosys layer: when mapping LUTs back to RTL cells, a single LUT may cover multiple original AIG objects. Yosys already has infrastructure for merging \src attributes (e.g., \src "foo.v:10|bar.v:20"), so it can union the \src values of all original objects that a LUT's origin chain touches. ABC just needs to provide the single best origin per object as an anchor for that lookup. Single origin per object implies that the src attribution is lossy. When nodes are merged in abc, you are then forcing one origin only among multiple possibilities. I think this solution is strictly worse than what we had implemented, where we allow for up to N src attributes. Yes, it's more complicated, but it's higher fidelity. Your point about handling multi-src attribution in Yosys is irrelevant, because the information loss happens in abc. — Reply to this email directly, view it on GitHub <#487 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB4O4FEPR5VSFPK37MUW2L4P4FYVAVCNFSM6AAAAACWCKO2UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMRVHEZTQNZQGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[akashlevy]

Ah, it’s one origin per input object. Check the Yosys patch for more details.
…
On Mon, 9 Mar 2026 at 18:40, Akash Levy @.> wrote: akashlevy left a comment (berkeley-abc/abc#487) <#487 (comment)> @akashlevy https://github.com/akashlevy Single origin per object — each GIA object maps to one ancestor in the original AIG. This keeps the tracking lightweight (one int per object, zero allocations on the hot path). Multi-source attribution is better handled at the Yosys layer: when mapping LUTs back to RTL cells, a single LUT may cover multiple original AIG objects. Yosys already has infrastructure for merging \src attributes (e.g., \src "foo.v:10|bar.v:20"), so it can union the \src values of all original objects that a LUT's origin chain touches. ABC just needs to provide the single best origin per object as an anchor for that lookup. Single origin per object implies that the src attribution is lossy. When nodes are merged in abc, you are then forcing one origin only among multiple possibilities. I think this solution is strictly worse than what we had implemented, where we allow for up to N src attributes. Yes, it's more complicated, but it's higher fidelity. Your point about handling multi-src attribution in Yosys is irrelevant, because the information loss happens in abc. — Reply to this email directly, view it on GitHub <#487 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB4O4FEPR5VSFPK37MUW2L4P4FYVAVCNFSM6AAAAACWCKO2UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMRVHEZTQNZQGU . You are receiving this because you were mentioned.Message ID: @.>

Ah got it! So there can still be multiple src attrs on the output objects as merge operations happen?

[robtaylor]

Ah, it’s one origin per input object. Check the Yosys patch for more details.
…
On Mon, 9 Mar 2026 at 18:40, Akash Levy @.> wrote: akashlevy left a comment (berkeley-abc/abc#487) <#487 (comment)> @akashlevy https://github.com/akashlevy Single origin per object — each GIA object maps to one ancestor in the original AIG. This keeps the tracking lightweight (one int per object, zero allocations on the hot path). Multi-source attribution is better handled at the Yosys layer: when mapping LUTs back to RTL cells, a single LUT may cover multiple original AIG objects. Yosys already has infrastructure for merging \src attributes (e.g., \src "foo.v:10|bar.v:20"), so it can union the \src values of all original objects that a LUT's origin chain touches. ABC just needs to provide the single best origin per object as an anchor for that lookup. Single origin per object implies that the src attribution is lossy. When nodes are merged in abc, you are then forcing one origin only among multiple possibilities. I think this solution is strictly worse than what we had implemented, where we allow for up to N src attributes. Yes, it's more complicated, but it's higher fidelity. Your point about handling multi-src attribution in Yosys is irrelevant, because the information loss happens in abc. — Reply to this email directly, view it on GitHub <#487 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB4O4FEPR5VSFPK37MUW2L4P4FYVAVCNFSM6AAAAACWCKO2UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMRVHEZTQNZQGU . You are receiving this because you were mentioned.Message ID: _@**.**_>

Ah got it! So there can still be multiple src attrs on the output objects as merge operations happen?

yes indeed, thats the point =)

[robtaylor]

To clarify my earlier reply — let me be more precise about what's happening.

You're right that single origin per object is lossy within ABC. There are two loss points:

1. Structural sharing: when hashing finds an existing equivalent node, the new node's origin is discarded (the existing node keeps its origin)
2. New nodes: AND(a, b) inherits min(origin(a), origin(b)) — the other input's origin is dropped

The Yosys-side multi-source collection partially compensates: for each mapped LUT, it collects \src from the output object's origin AND each input object's origin (up to K+1 anchors for a K-input LUT). This recovers attribution from the cut boundary, but interior nodes of the LUT cone are not individually tracked.

So in practice: the coverage is good for typical RTL (structurally identical sub-expressions from different source locations are uncommon), but it is not lossless. An N-origins-per-object approach would be higher fidelity at the cost of N× memory and significantly more complex propagation through all the engine paths. The current design is a pragmatic starting point — if real-world usage shows the loss matters, the origin field could be extended.

[akashlevy]

To clarify my earlier reply — let me be more precise about what's happening.

You're right that single origin per object is lossy within ABC. There are two loss points:

1. Structural sharing: when hashing finds an existing equivalent node, the new node's origin is discarded (the existing node keeps its origin)
2. New nodes: AND(a, b) inherits min(origin(a), origin(b)) — the other input's origin is dropped

The Yosys-side multi-source collection partially compensates: for each mapped LUT, it collects \src from the output object's origin AND each input object's origin (up to K+1 anchors for a K-input LUT). This recovers attribution from the cut boundary, but interior nodes of the LUT cone are not individually tracked.

So in practice: the coverage is good for typical RTL (structurally identical sub-expressions from different source locations are uncommon), but it is not lossless. An N-origins-per-object approach would be higher fidelity at the cost of N× memory and significantly more complex propagation through all the engine paths. The current design is a pragmatic starting point — if real-world usage shows the loss matters, the origin field could be extended.

Got it. I suppose it depends on the application you are going for. Having one src attribute is obviously better than having none.

But an issue that can happen (we've seen happen) is "aliasing" of many final nodes to a single origin node. In reality, these final nodes have a large diversity of origins, which is evident when multi-src attribution is kept.

For our application (giving users an understanding of power/perf/area bottlenecks), it's not ideal to say, "this is the only line of RTL that led to this bottleneck" when in reality, it was multiple.

[robtaylor]

@alanminko @akashlevy Thinking about this further — there's a middle ground between single-origin and N-origins-per-object that could address the fidelity concern without the memory overhead.

The origin loss happens at two specific points in structural hashing (giaHash.c):

1. Hash hit: an equivalent node already exists, so the new node's origin is silently discarded
2. New node: AND(a,b) picks min(origin(a), origin(b)), dropping the other

Since these merge events are relatively rare compared to total node count, we could keep a global merge log — a flat vector of (node_id, discarded_origin) pairs in Gia_Man_t:

Vec_Int_t * vOriginsMerged;  // append-only pairs: (node_id, alt_origin)

This is sparse and append-only — no per-object overhead, just a small side table for the rare merge events. Propagation through Dup functions would remap node IDs the same way Gia_ManOriginsDup does (via the Value field), and the list stays small.

For XAIGER transport, the merge log could be a new extension (e.g., "z") carrying (object_id, alt_origin) pairs alongside the existing "y" extension. Yosys would then include those additional \src values when mapping LUTs back to RTL.

The main subtlety is multi-pass optimization: a node merged in pass 1 might get further merged in pass 2, creating chains. These would need transitive resolution through the origin mapping at write time.

Alan — would something like this be acceptable as an addition to vOrigins, or would it add too much complexity to the core data structures?

[akashlevy]

This proposed solution sounds like it would achieve multi-src attribution properly, just in a slightly different way than we had done in our fork. No need to have per-node arrays until the end. Seems like it would work well.

I will say that the merge events are not as rare as you might think for a typical design. Transitive resolution would be necessary in quite a few real-world cases.

[robtaylor]

This proposed solution sounds like it would achieve multi-src attribution properly, just in a slightly different way than we had done in our fork. No need to have per-node arrays until the end. Seems like it would work well.

I will say that the merge events are not as rare as you might think for a typical design. Transitive resolution would be necessary in quite a few real-world cases.

ah, but is it rare with respect to the total number of nodes?

[akashlevy]

This proposed solution sounds like it would achieve multi-src attribution properly, just in a slightly different way than we had done in our fork. No need to have per-node arrays until the end. Seems like it would work well.
I will say that the merge events are not as rare as you might think for a typical design. Transitive resolution would be necessary in quite a few real-world cases.

ah, but is it rare with respect to the total number of nodes?

No, it's very common. We see about 4-5 src attributes per node on average, when we retain thru merge.

[akashlevy]

This proposed solution sounds like it would achieve multi-src attribution properly, just in a slightly different way than we had done in our fork. No need to have per-node arrays until the end. Seems like it would work well.
I will say that the merge events are not as rare as you might think for a typical design. Transitive resolution would be necessary in quite a few real-world cases.

ah, but is it rare with respect to the total number of nodes?

No, it's very common. We see about 4-5 src attributes per node on average, when we retain thru merge.

We are also using a pretty aggressive abc recipe though, so this could be why the number we see is so high.

[alanminko]

@alanminko @akashlevy Thinking about this further — there's a middle ground between single-origin and N-origins-per-object that could address the fidelity concern without the memory overhead.

The origin loss happens at two specific points in structural hashing (giaHash.c):

1. Hash hit: an equivalent node already exists, so the new node's origin is silently discarded
2. New node: AND(a,b) picks min(origin(a), origin(b)), dropping the other

Since these merge events are relatively rare compared to total node count, we could keep a global merge log — a flat vector of (node_id, discarded_origin) pairs in Gia_Man_t:

Vec_Int_t * vOriginsMerged;  // append-only pairs: (node_id, alt_origin)

This is sparse and append-only — no per-object overhead, just a small side table for the rare merge events. Propagation through Dup functions would remap node IDs the same way Gia_ManOriginsDup does (via the Value field), and the list stays small.

For XAIGER transport, the merge log could be a new extension (e.g., "z") carrying (object_id, alt_origin) pairs alongside the existing "y" extension. Yosys would then include those additional \src values when mapping LUTs back to RTL.

The main subtlety is multi-pass optimization: a node merged in pass 1 might get further merged in pass 2, creating chains. These would need transitive resolution through the origin mapping at write time.

Alan — would something like this be acceptable as an addition to vOrigins, or would it add too much complexity to the core data structures?

It will be acceptable as long as it is helpful for the Yosys team and other users and the default behavior of ABC is not changed. I do not have immediate plans to use this feature and this is why I do not have a preference regarding a good tradeoff for this data-structure (compactness vs expressiveness).