From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26178 invoked by alias); 26 Dec 2004 20:16:35 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26120 invoked by uid 48); 26 Dec 2004 20:16:31 -0000 Date: Sun, 26 Dec 2004 20:16:00 -0000 From: "rth at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org Message-ID: <20041226201629.19161.rth@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/19161] New: No emms or femms emitted between MMX and FP instructions X-Bugzilla-Reason: CC X-SW-Source: 2004-12/txt/msg03564.txt.bz2 List-Id: 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