A simple <MOVS rd, imm8> can materialize [-128, 127] in signed i8 type or [0, 255] in unsigned i8 type on Thumb1.
Ah, but looking a bit closer now, I am not sure this is the right thing to do. This changes makes any 8 bit value cheap, including negative numbers. And I am not sure if this is the right thing to do, since the Thumb1 immediates are positive numbers. It looks this a workaround for store-merging interacting badly with constant hoisting.
Is this because we can just use a MOVS and wont have to fill in any higher bits? And MOVS's aren't trivially rematerialisable? And Thumb2/Arm are handled by getT2SOImmVal?
So, yeah, looks sensible to me, and this does seem to reduce codesize. But please clean up the testcase.
Depends on how it's interpreted, 0xFF is -1 in signed i8 or 255 in unsigned i8.
Right, constant hoisting breaks store merging for this case.
Yes, since it's i8 type, no need to deal with higher bits. We ran into this case with internal workload, it's intended to reduce code size.