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


  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: link
Be 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).