This patchset marks all the CPUs that support iwMMXt as deprecated,
because I don't believe anybody is using them, and we have no way to
test the thousands of lines of code we have that's only there for
iwMMXt emulation. (See for instance the recent thread where a patch
was submitted to fix an issue detected by a static analyzer: we
didn't take it, largely because we had no way to know if the
behaviour change the patch would produce was correct or not.)
The pxa2xx CPUs are now only useful with user-mode emulation, because
we dropped all the machine types that used them in 9.2. (Technically
you could alse use "-cpu pxa270" with a board model like versatilepb
which doesn't sanity-check the CPU type, but that has never been a
supported config.)
To use them (or iwMMXt emulation) with QEMU user-mode you would need
to explicitly select them with the -cpu option or the QEMU_CPU
environment variable, because the '-cpu max' default CPU does not
include iwMMXt emulation. A google search finds no examples of
anybody doing this in the last decade.
I asked some of the Linaro GCC folks if they were using QEMU to test
their iwMMXt codegen, or knew anybody doing that upstream, and the
answer was "no". In fact, GCC is in the process of dropping support
for iwMMXt entirely.
We have one test case in check-tcg which purports to be checking
iwMMXt. In fact it is doing no such thing: it runs the test without
selecting an iwMMXt CPU, which means the iwMMXt insns are interpreted
as FPA11 insns by the linux-user emulate_arm_fpa11() code. So the test
prints garbage and then succeeds anyway. Modern distro toolchains
can't generate a binary that will run with -cpu pxa270 (because their
crt startup code uses Thumb insns); rather than putting in a lot of
effort trying to salvage the test case to really test a feature we've
deprecated, I opted to just remove the test.