Digging into this case I see
```
if (TARGET_USE_MOVT)
arm_emit_movpair (target, GEN_INT (val));
else
emit_set_insn (target, GEN_INT (val));
```
at the point where we decide whether or not to use MOVW/MOVT. But
`TARGET_USE_MOVT` is dependent on the CPU tuning property
`prefer_constant_pool`, which is dependent on the CPU tuning tables. However,
this is ignored when literal pools are disabled.
So while your patch will address the problem for m-profile devices, it doesn't
really solve the problem everywhere in a reliable manner.
Looking back at the history of this test, I see it was originally added to
check that _when_ we emit a mov-pair sequence we emit a note on the sequence
with the REG_EQUAL of the final value.
I don't think it really matters that we test this for every CPU that supports
mov-pair; we just want to assert the above property. So I'm now thinking we
should change the test to force the pre-conditions to be true by requiring a
CPU that has these properties and then applying the options needed to achieve
this. A suitable cpu target would be cortex-a53, for which we already have
support in target-supports.exp.
--
https://forge.sourceware.org/gcc/gcc/pulls/198#issuecomment-6835
