From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26016 invoked by alias); 19 Dec 2006 14:57:52 -0000 Received: (qmail 25944 invoked by uid 48); 19 Dec 2006 14:57:34 -0000 Date: Tue, 19 Dec 2006 14:57:00 -0000 Message-ID: <20061219145734.25943.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/30255] register spills in x87 unit need to be 80-bit, not 64 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ian at airs dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-12/txt/msg01594.txt.bz2 ------- Comment #8 from ian at airs dot com 2006-12-19 14:57 ------- I think I agree that if we spill an 80387 register to the stack, and then load the value back into an 80387 register, that we should spill all 80 bits, rather than implicitly converting to DFmode or SFmode. This would unfortunately be rather difficult to implement in the context of gcc's register allocator, because it is perfectly normal for gcc to spill values from one type of register and reload them into a different type of register. Thus the value might move between an 80387 register, a pair of ordinary x86 registers, and an SSE/SSE2 register, all in the same function. It would just depend on how the value was being used. Currently gcc simply says the value is DFmode or SFmode, and more or less ignores the fact that it is being represented as an 80-bit value in an 80387 register. To implement this suggestion we would need to add a new notion: the mode of the spill value. And we would need to support secondary reloads to convert 80-bit spill values as required. That sounds rather complicated, but if we didn't do that, then I think we would still be inconsistent in some cases. I don't see any point to making this change unless we can always be consistent. All in all it's pretty hard for me to get excited about better support for 80387 when all modern x87 chips support SSE2 which is more consistent and faster. See the option -mfpmath=sse. -- ian at airs dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255