public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ian at airs dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/30255] register spills in x87 unit need to be 80-bit, not 64 Date: Tue, 19 Dec 2006 14:57:00 -0000 [thread overview] Message-ID: <20061219145734.25943.qmail@sourceware.org> (raw) In-Reply-To: <bug-30255-12761@http.gcc.gnu.org/bugzilla/> ------- 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
next prev parent reply other threads:[~2006-12-19 14:57 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-12-18 20:08 [Bug target/30255] New: " whaley at cs dot utsa dot edu 2006-12-18 20:16 ` [Bug target/30255] " pinskia at gcc dot gnu dot org 2006-12-18 20:43 ` whaley at cs dot utsa dot edu 2006-12-18 21:17 ` whaley at cs dot utsa dot edu 2006-12-18 22:04 ` pinskia at gcc dot gnu dot org 2006-12-18 22:14 ` whaley at cs dot utsa dot edu 2006-12-18 23:03 ` pinskia at gcc dot gnu dot org 2006-12-19 0:32 ` whaley at cs dot utsa dot edu 2006-12-19 14:57 ` ian at airs dot com [this message] 2006-12-19 16:04 ` whaley at cs dot utsa dot edu 2006-12-19 17:18 ` whaley at cs dot utsa dot edu 2006-12-27 16:22 ` rguenth at gcc dot gnu dot org [not found] <bug-30255-4@http.gcc.gnu.org/bugzilla/> 2014-02-16 13:13 ` jackie.rosen at hushmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20061219145734.25943.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).