Repository navigation
[rocjitsu] Return SOPP encoding errors as results - #14403
Conversation
Signed-off-by: Ian Wood <ianwood@u.northwestern.edu>
✅ All Checks Passed — Ready for Review
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🎉 All checks passed! This PR is ready for review. |
kuhar
left a comment
kuhar
left a comment
There was a problem hiding this comment.
Should we also forward error through the build_sopp_encoding calls in build_wait_scalar_loads_complete (emulation/rocjitsu/lib/rocjitsu/src/rocjitsu/code/builders/smem_builders.h:228, with the same pattern through line 246)? With the new emitter parameter in emulation/rocjitsu/lib/rocjitsu/src/rocjitsu/code/builders/instruction_builder.h:124, this caller already forwards the result but leaves its diagnostic context behind. Passing the same emitter would keep the two parts of the composed API together. This is optional plumbing cleanup: every current architecture case succeeds, so there is no missing diagnostic on a reachable failure today.
Signed-off-by: Ian Wood <ianwood@u.northwestern.edu>
rocjitsu post-commit fuzz passedThe 32-worker multiplexer campaigns for commit
|
TheRock Submodule Bump ActivityNewest first
|
Motivation
Remove the explicit unsupported-architecture throw from
build_sopp_encoding.Technical Details
Return
FailureOrwith optional diagnostics and update callers to propagate failure or unwrap after architecture validation. Other SOPP opcode helpers and frontends retain their existing exceptions for a later change.Cover unsupported-architecture results and diagnostics, and update existing encoding and DBI tests for the result contract.
Issue Tracking
Part of #10239.