This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patches] Re: recognize x86 CPU variants and default SSE/MMX/3dNOW support
- From: John Vickers <jvickers at pace dot co dot uk>
- To: Brad Lucier <lucier at math dot purdue dot edu>
- Cc: jh at suse dot cz, aj at suse dot de, gcc-patches at gcc dot gnu dot org
- Date: Tue, 11 Dec 2001 19:32:07 +0000
- Subject: Re: [patches] Re: recognize x86 CPU variants and default SSE/MMX/3dNOW support
- Organization: Pace Microtechnology Plc
- References: <200112111857.fBBIvMq17353@banach.math.purdue.edu>
Brad Lucier wrote:
>
> Re:
>
> > > Jan Hubicka <jh@suse.cz> writes:
> > > > What is wrong with defaulting to SSE math on these CPUs? It is faster so I
> > > > believe it is similar as when we enable conditional moves or other use of given
> > > > architecture. We probably can have switch for backward compatibility with
> > > > i386 80bit temporaries, but I would still like to see SSE math to default
> > > > on SSE, mainly SSE2 enabled chips.
> > > > We cannot switch to SSE math since for ia32 since it would violate
> > > some assumptions people make about floating point precission (all
> > > evolution done in 80-bit) on Linux. This would give different
> > > numeric results depending on the switch.
> > Yes, but we already do give different results depending on -O switches
> > and gcc version, so I still don't think it is much worse.
>
> Just because gcc fp is, in some sense, broken now using x87 instructions on
> i386, doesn't mean that it's OK to make it more broken.
>
> I, personally, may prefer to use SSE arithmetic because of the greater
> predictability it gives me when using gcc,
> but I can imagine situations
> where I'd be mighty irritated if I carefully wrote some code that
> assumed extended double intermediate calculations and gcc changed it
> to double precision without telling me.
Presumably in such a case one would would be careful to use long double
variables, so the compiler wouldn't have any choice.
> > Gcc is allowed to truncate the value anytime it wants to.
>
> Gcc *does* truncate the value anytime it wants to. Whether it is
> *allowed to* is another matter. I would say no.
It currently rounds fewer times, or to greater precision,
than it is "allowed to". The problem is random excess precision.
Personally, I'd insert loads & stores to force proper rounding
by default. If it cripples the performance, I'd just say it
was because the architecture is, as Craig Burley put it, "Broken"
and "Stupid" (in the full technical senses ;-).
OTOH, not many folks would buy that. Some would.
My 2d.
John.
>
> Brad