Constants can also be materialised using the negated value and a MVN, and this
case seem to have been missed for Thumb2. To check the constant materialisation
costs, we now call getT2SOImmVal twice, once for the original constant and then
also for its negated value, and this function checks if the constant can both
be splatted or rotated.
This was revealed by a test that optimises for minsize: instead of a LDR
literal pool load and having a literal pool entry, just a MVN with an immediate is
smaller (and also faster). This gives a small code size improvement for all our
apps in our code corpus, only 2 test cases have a tiny, insignificant
regression.
I don't think the change from getT2SOImmValSplatVal to getT2SOImmVal makes much practical difference; isThumbImmShiftedVal covers the same cases. But I guess it's more clear, at least.
Maybe fix the MOV/MVN/MOVW comments so they're each on the same line as the corresponding check?