[TargetInstrInfo] update INLINEASM memoperands once #74135
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In commit b053359 ("[X86InstrInfo] support memfold on spillable inline asm
(#70832)"), I had a last minute fix to update the memoperands. I originally
did this in the parent foldInlineAsmMemOperand call, updated the mir test via
update_mir_test_checks.py, but then decided to move it to the child call of
foldInlineAsmMemOperand.
But I forgot to rerun update_mir_test_checks.py. That last minute change caused
the same memoperand to be added twice when recursion occurred (for tied
operands). I happened to get lucky that trailing content omitted from the
CHECK line doesn't result in test failure.
But rerunning update_mir_test_checks.py on the mir test added in that commit
produces updated output. This is resulting in updates to the test that:
conflate additions to the test in child commits with simply updating the
test as it should have been when first committed.
look wrong because the same memoperand is specified twice (we don't
deduplicate memoperands when added). Example:
INLINEASM ... :: (load (s32) from %stack.0) (load (s32) from %stack.0)
Fix the bug, so that in child commits, we don't have additional unrelated test
changes (which would be wrong anyways) from simply running
update_mir_test_checks.py.
Link: #20571