public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: target/5381: compiler does not issue emmx
@ 2002-01-15 4:26 Richard Henderson
0 siblings, 0 replies; 2+ messages in thread
From: Richard Henderson @ 2002-01-15 4:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR target/5381; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: David Kastrup <David.Kastrup@t-online.de>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/5381: compiler does not issue emmx
Date: Tue, 15 Jan 2002 04:16:03 -0800
On Tue, Jan 15, 2002 at 09:07:37AM +0100, David Kastrup wrote:
> If the user put emmx instructions in at a place where the compiler
> decided to leave a variable in an MMX register for optimization purposes...
Nope. The __builtin_emmx function clobbers all of the mmx registers,
so the compiler knows that any spillage must happen before that.
r~
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: target/5381: compiler does not issue emmx
@ 2002-01-15 0:16 David Kastrup
0 siblings, 0 replies; 2+ messages in thread
From: David Kastrup @ 2002-01-15 0:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR target/5381; it has been noted by GNATS.
From: David.Kastrup@t-online.de (David Kastrup)
To: Richard Henderson <rth@redhat.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/5381: compiler does not issue emmx
Date: 15 Jan 2002 09:07:37 +0100
Richard Henderson <rth@redhat.com> writes:
> Not a bug -- pmulhuw is an SSE instruction, not part of
> the base MMX instruction set.
Oops, sorry. Darn those spec sheets that don't bother mentioning
this. Probably MMX2 or something.
But here to the second problem that I consider real:
> > Anyhow, as you can see from the generated code, the compiler fails to
> > emit an emmx instruction at the end of the routine, leading to possible
> > floating point errors after return.
>
> Again, not a bug. The user is responsible for handling emmx.
>
> If the compiler were deciding to emit MMX code on its own,
> then yes I would agree that it must clean up after itself.
> But this is not the case here.
The problem is that the compiler is allocating the MMX registers used,
might be rearranging expressions including floating point operands in
between, and is possibly doing optimizations that might move the
__builtin_ functions. It is the use of the MMX registers that
necessitates the emmx instruction before the next floating point
instruction. Since the compiler is the one in control that clobbers
the registers, and since it is the one that knows when it will next
need the floating point stack and will have to flush any remaining MMX
registers back to memory, it stands to reason that it should also be
responsible for issuing the emmx instruction. If the user put emmx
instructions in at a place where the compiler decided to leave a
variable in an MMX register for optimization purposes, things get
ugly.
I would even go as far as to claim that the compiler should issue an
emmx instruction if it has assigned mmx registers due to a "y"
contraint on assembly language templates: after all, it is only after
the template finishes that any output operands can be moved into
memory locations or reused for the a possibly coming up MMX
instruction, so putting an emmx instruction into your assembly
template yourself would definitely be impossible. Adding another
assembly template afterwards and hoping that the compiler will have
cleared out registers before its execution is just crossing fingers
and second-guessing.
As long as the compiler is in charge of assigning the registers, it
should also be in charge of telling the CPU when it is done.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-01-15 12:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-15 4:26 target/5381: compiler does not issue emmx Richard Henderson
-- strict thread matches above, loose matches on Subject: below --
2002-01-15 0:16 David Kastrup
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).