google
Refine proc inlining activation for cover
What's hard to do? (limit 100 words)
Before removing tokens from these operations in #1234, these nodes were naturally part of the virtual proc thread activation network for the proc inlining pass. This ensured that the ops only fired when their data inputs (which might be dependent on a receive) were valid.
Once these nodes no longer have associated tokens, it is difficult to pin these nodes to a precise point in the activation network. These nodes no longer have any predecessors, and it's not correct to activate with the proc activation. Tracing operands back to their token nodes (if any) and then creating an implicit node joining these tokens might be an ideal if tedious solution.
Current best alternative workaround (limit 100 words)
Without tokens anymore, as a simplified workaround, we simply associate these side effecting nodes with the activation sink node. This ensure that they always fire after any data inputs activate in the proc.
One caveat is that by waiting until the very end of of the activation network, it's possible that an assertion won't fire while the proc is stalled on some unrelated receive. Previously, the assertion could fire once its data inputs were activated, as long as it didn't trace back to that receive.
Your view of the "best case XLS enhancement" (limit 100 words)
Asserts/covers/traces should still activate in the "correct" sequence within the activation network after proc inlining.
