Curse Intel and their modal register sets.
Today I caught the x86-64 compiler using %mm0 just because the datatype it
wanted to move fit nicely in that register. Except that after an MMX register
is touched, one must leave MMX mode before (1) the nest FPU instruction or
(2) at a call boundary, since the abi requires we be in FPU mode.
Not bothering to add a test case, since I'm planning to hack around this
specific example with changed register preferences, but the point remains
that we have nothing in place to prevent the badness.
I suspect that what we'll need for a complete solution may include dynamic
register class letters. At some point, perhaps during rtl expansion, we
record whether or not there are any *operations* that require either MMX
or FPU. If we have MMX but not FPU operations, we set 'f' to NOREGS; if
we have FPU but not MMX, we set 'y' to NOREGS. If we have both, then then
we'll need an optimize_mode_switching pass to swap between modes. The
exceedingly tricky bit there will be tricking reload into not making both
kinds of registers live behind our backs.
--
Summary: No emms or femms emitted between MMX and FP instructions
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i386-*-* x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
