SIFoldOperands::foldInstOperand folds an immediate value into any number
of inline immediates uses, but it was missing uses that could be inline
if the instruction was commuted. The test diffs mostly show cases where
the immediate value 0 can be folded into more than one commuted v_addc
instruction.
Unfortunately this adds more duplication between
isInlineConstantIfFolded and tryAddToFoldList, but there was already
duplication of the mac/mad handling.
It occurs to me now that SIFoldOperands would probably have succeeded here if these were using the e64 form of the instruction. But there are obviously real world cases where it sees the e32 form, otherwise none of the .ll tests would have been improved by this patch.
Is it worth abandoning this patch and pursuing why we are selecting e32 instructions in the first place?