Change x86 default arch for 4.5?

Change x86 default arch for 4.5?

[Jason Merrill]

I periodically get bitten by bug 34115: a compiler configured without 
--with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we 
would only need to bump the default to i486 to get atomic support.  Can 
we reconsider the default for 4.5?

Jason

Re: Change x86 default arch for 4.5?

[Joe Buck]

On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote:
> I periodically get bitten by bug 34115: a compiler configured without 
> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we 
> would only need to bump the default to i486 to get atomic support.  Can 
> we reconsider the default for 4.5?

Is anyone still manufacturing x86 CPUs that don't support the atomic
instructions?

Re: Change x86 default arch for 4.5?

[David Daney]

On 02/18/2010 03:30 PM, Joe Buck wrote:
> On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote:
>> I periodically get bitten by bug 34115: a compiler configured without
>> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we
>> would only need to bump the default to i486 to get atomic support.  Can
>> we reconsider the default for 4.5?
>
> Is anyone still manufacturing x86 CPUs that don't support the atomic
> instructions?

Should it just be a question of 'manufacturing'?  Or should 'using' be a 
criterion for any decision?

Not that I disagree with Jason's suggestion, it is probably the right 
choice.

David Daney

Re: Change x86 default arch for 4.5?

[Joseph S. Myers]

On Thu, 18 Feb 2010, Jason Merrill wrote:

> I periodically get bitten by bug 34115: a compiler configured without
> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we would
> only need to bump the default to i486 to get atomic support.  Can we
> reconsider the default for 4.5?

My position remains that configuring for i686-* should default to 
-march=i686 rather than -mtune=i686.

http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html
http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html

Perhaps someone would like to review HJ's patch to that effect?

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html

This will probably break building glibc, as problems building when __i686 
is a predefined macro have been known since at least 2002 but none of the 
many patches proposed since then have been accepted.

http://sourceware.org/ml/libc-alpha/2002-10/msg00156.html
 ...
http://sourceware.org/ml/libc-alpha/2009-07/msg00072.html

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Change x86 default arch for 4.5?

[Joe Buck]

On Thu, Feb 18, 2010 at 04:31:37PM -0800, David Daney wrote:
> On 02/18/2010 03:30 PM, Joe Buck wrote:
> > On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote:
> >> I periodically get bitten by bug 34115: a compiler configured without
> >> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we
> >> would only need to bump the default to i486 to get atomic support.  Can
> >> we reconsider the default for 4.5?
> >
> > Is anyone still manufacturing x86 CPUs that don't support the atomic
> > instructions?
> 
> Should it just be a question of 'manufacturing'?  Or should 'using' be a 
> criterion for any decision?

> Not that I disagree with Jason's suggestion, it is probably the right 
> choice.

"using" would be the right criterion if Jason were advocating removing
support for i386 but he only proposed changing the default.

But maybe I didn't ask the right question: can any x86 experts comment on
recently made x86 CPUs that would not function correctly with code
produced by --with-arch=i486?  Are there any?

Re: Change x86 default arch for 4.5?

[Tim Prince]

On 2/18/2010 4:54 PM, Joe Buck wrote:
>
> But maybe I didn't ask the right question: can any x86 experts comment on
> recently made x86 CPUs that would not function correctly with code
> produced by --with-arch=i486?  Are there any?
>
>    
All CPUs still in production are at least SSE3 capable, unless someone 
can come up with one of which I'm not aware.  Intel compilers made the 
switch last year to requiring SSE2 capability for the host, as well as 
in the default target options, even for 32-bit.  All x86_64 or X64 CPUs 
for which any compiler was produced had SSE2 capability, so it is 
required for those 64-bit targets.

-- 
Tim Prince

Re: Change x86 default arch for 4.5?

[Jason Merrill]

On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
> On Thu, 18 Feb 2010, Jason Merrill wrote:
>
>> I periodically get bitten by bug 34115: a compiler configured without
>> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we would
>> only need to bump the default to i486 to get atomic support.  Can we
>> reconsider the default for 4.5?
>
> My position remains that configuring for i686-* should default to
> -march=i686 rather than -mtune=i686.

That makes sense to me.

> Perhaps someone would like to review HJ's patch to that effect?
>
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html

Using all the noncanonical variants as arch defaults makes me a bit 
nervous, but I suppose if someone actually writes $GCC/configure 
nocona-pc-linux-gnu that's what they would expect to get...

> This will probably break building glibc, as problems building when __i686
> is a predefined macro have been known since at least 2002 but none of the
> many patches proposed since then have been accepted.

I imagine changing the default would help with that...and packagers can 
work around it.

Jason

Re: Change x86 default arch for 4.5?

[Paolo Bonzini]

>> This will probably break building glibc, as problems building when __i686
>> is a predefined macro have been known since at least 2002 but none of the
>> many patches proposed since then have been accepted.
>
> I imagine changing the default would help with that...and packagers can
> work around it.

I think that many packagers already are.

Paolo

Re: Change x86 default arch for 4.5?

[Joe Buck]

On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote:
> On 2/18/2010 4:54 PM, Joe Buck wrote:
> >
> > But maybe I didn't ask the right question: can any x86 experts comment on
> > recently made x86 CPUs that would not function correctly with code
> > produced by --with-arch=i486?  Are there any?
> >
> >    
> All CPUs still in production are at least SSE3 capable, unless someone 
> can come up with one of which I'm not aware.  Intel compilers made the 
> switch last year to requiring SSE2 capability for the host, as well as 
> in the default target options, even for 32-bit.  All x86_64 or X64 CPUs 
> for which any compiler was produced had SSE2 capability, so it is 
> required for those 64-bit targets.

I'm sure that Intel and AMD haven't made any in ages, I just wanted to
make sure that there are no low-end third-party cores made recently (say,
by Cyrix, VIA, or someone else) that lack atomics.  I guess that the
answer is no.

Re: Change x86 default arch for 4.5?

[Florian Weimer]

* Tim Prince:

> All CPUs still in production are at least SSE3 capable, unless someone
> can come up with one of which I'm not aware.

What about some of the AMD Geode processors?

Re: Change x86 default arch for 4.5?

[Joel Dice]

On Fri, 19 Feb 2010, Florian Weimer wrote:

> * Tim Prince:
>
>> All CPUs still in production are at least SSE3 capable, unless someone
>> can come up with one of which I'm not aware.
>
> What about some of the AMD Geode processors?

These only support a subset of SSE1, according to 
http://wiki.laptop.org/go/Geode_instruction_set.

Here is an excerpt from /proc/cpuinfo on my Geode LX:

flags		: fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow

Re: Change x86 default arch for 4.5?

[Erik Trulsson]

On Fri, Feb 19, 2010 at 09:31:12AM -0800, Joe Buck wrote:
> On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote:
> > On 2/18/2010 4:54 PM, Joe Buck wrote:
> > >
> > > But maybe I didn't ask the right question: can any x86 experts comment on
> > > recently made x86 CPUs that would not function correctly with code
> > > produced by --with-arch=i486?  Are there any?
> > >
> > >    
> > All CPUs still in production are at least SSE3 capable, unless someone 
> > can come up with one of which I'm not aware.  Intel compilers made the 
> > switch last year to requiring SSE2 capability for the host, as well as 
> > in the default target options, even for 32-bit.  All x86_64 or X64 CPUs 
> > for which any compiler was produced had SSE2 capability, so it is 
> > required for those 64-bit targets.
> 
> I'm sure that Intel and AMD haven't made any in ages,

Depends on what you mean by ages. Intel did not stop producing actual
80386 (and 80486) processors until as late as 2007 (for use in embedded
systems.)   Looking around at Intel's homepage for embedded processors
I find references to Pentium-MMX processors, but I am not sure about
the actual status of those.  (Those old CPUs probably haven't been used
for any new designs for quite a while, but older designs using them
might still be in prodcution.)
Amd seems to still be producing the Geode-LX series which do not seem
to support SSE at all (only MMX and 3dnow.)

However to answer the original question I believe that all x86
variants that are still actively developed for support at least the
full 80486 instruction set.


> I just wanted to
> make sure that there are no low-end third-party cores made recently (say,
> by Cyrix, VIA, or someone else) that lack atomics.  I guess that the
> answer is no.
> 

-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: Change x86 default arch for 4.5?

[Steven Bosscher]

On Fri, Feb 19, 2010 at 6:31 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote:
>> On 2/18/2010 4:54 PM, Joe Buck wrote:
>> >
>> > But maybe I didn't ask the right question: can any x86 experts comment on
>> > recently made x86 CPUs that would not function correctly with code
>> > produced by --with-arch=i486?  Are there any?
>> >
>> >
>> All CPUs still in production are at least SSE3 capable, unless someone
>> can come up with one of which I'm not aware.  Intel compilers made the
>> switch last year to requiring SSE2 capability for the host, as well as
>> in the default target options, even for 32-bit.  All x86_64 or X64 CPUs
>> for which any compiler was produced had SSE2 capability, so it is
>> required for those 64-bit targets.
>
> I'm sure that Intel and AMD haven't made any in ages, I just wanted to
> make sure that there are no low-end third-party cores made recently (say,
> by Cyrix, VIA, or someone else) that lack atomics.  I guess that the
> answer is no.

Forgive me my ignorance, but... Why is this important/relevant?

As a user of GCC, I would expect the compiler to generate good code
for reasonably modern targets in the default settings. The number of
machines that are still based on i386, i486, or even Pentium, is a
barely significant minority, yet gcc will by default satisfy the needs
of this minority and make it more difficult for the average user to
get good code out of the compiler.

I work a lot with software developers that use gcc as just one of the
many compilers they use (usually they use gcc on linux-ix86 and
linux-x86_64, but hp for hppa, intel for itanium-linux, etc.). So far,
most of them do not add any -march or -mtune parameters to gcc, so
they end up with a program (a structural analysis code) that performs
less-than-optimal. One of these users had actually dropped gcc on
ix86-linux and x86_64-linux in favor of icc because gcc generated a
much slower program. I explained how to change the default settings
from i386 to pentium3, narrowing the performance gap to almost
nothing. This user now uses gcc for all supported linux based
platforms again.

My point: gcc may fail to attract users (and/or may be losing users)
when it tries to tailor to the needs of minorities.

IMHO it would be much more reasonable to change the defaults to
generate code that can run on, say, 95% of the computers still in use.
If a user want to use the latest-and-greatest gcc for a really old
machine, the burden of adding extra flags to change the default
behavior of the compiler should be on that user.

In this case of the i386 back end, that probably means changing the
default to something like pentium3.

Ciao!
Steven

Re: Change x86 default arch for 4.5?

[Paolo Carlini]

On 02/19/2010 01:46 AM, Joseph S. Myers wrote:
> On Thu, 18 Feb 2010, Jason Merrill wrote:
>   
>> I periodically get bitten by bug 34115: a compiler configured without
>> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we would
>> only need to bump the default to i486 to get atomic support.  Can we
>> reconsider the default for 4.5?
>>     
> My position remains that configuring for i686-* should default to 
> -march=i686 rather than -mtune=i686.
>
> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html
> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html
>
> Perhaps someone would like to review HJ's patch to that effect?
>   
Yes, please: for the record, I totally support this position.

Paolo.

Re: Change x86 default arch for 4.5?

[Geert Bosch]

On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
> My point: gcc may fail to attract users (and/or may be losing users)
> when it tries to tailor to the needs of minorities.
> 
> IMHO it would be much more reasonable to change the defaults to
> generate code that can run on, say, 95% of the computers still in use.
> If a user want to use the latest-and-greatest gcc for a really old
> machine, the burden of adding extra flags to change the default
> behavior of the compiler should be on that user.
> 
> In this case of the i386 back end, that probably means changing the
> default to something like pentium3.

The biggest change we need to make for x86 is to enable SSE2,
so we can get proper rounding behavior for float and double,
as well as significant performance increases.

  -Geert

Re: Change x86 default arch for 4.5?

[Richard Guenther]

On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch <bosch@adacore.com> wrote:
>
> On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
>> My point: gcc may fail to attract users (and/or may be losing users)
>> when it tries to tailor to the needs of minorities.
>>
>> IMHO it would be much more reasonable to change the defaults to
>> generate code that can run on, say, 95% of the computers still in use.
>> If a user want to use the latest-and-greatest gcc for a really old
>> machine, the burden of adding extra flags to change the default
>> behavior of the compiler should be on that user.
>>
>> In this case of the i386 back end, that probably means changing the
>> default to something like pentium3.
>
> The biggest change we need to make for x86 is to enable SSE2,
> so we can get proper rounding behavior for float and double,
> as well as significant performance increases.

I think Joseph fixed the rounding behavior for 4.5.  Also without an adjusted
ABI you'd introduce x87 <-> SSE register moves which are not helpful
for performance.

The present discussion is about defaulting to at least 486 when not
configured for i386-linux.  That sounds entirely reasonable to me.

Richard.

>  -Geert
>

Re: Change x86 default arch for 4.5?

[Paolo Carlini]

On 02/21/2010 01:13 PM, Richard Guenther wrote:
> The present discussion is about defaulting to at least 486 when not
> configured for i386-linux.  That sounds entirely reasonable to me.
>   
Again for the record, I like this too, if we can't do what Joseph suggests.

Paolo.

Re: Change x86 default arch for 4.5?

[Joseph S. Myers]

On Sun, 21 Feb 2010, Richard Guenther wrote:

> > The biggest change we need to make for x86 is to enable SSE2,
> > so we can get proper rounding behavior for float and double,
> > as well as significant performance increases.
> 
> I think Joseph fixed the rounding behavior for 4.5.  Also without an adjusted

Well, I provided the option for rounding that is predictable and in 
accordance with C99 when using the default -mfpmath=387.  But that option 
does carry the performance cost of storing to / loading from memory at 
various points, as required to get the rounding on 387 (and there are 
still cases where excess precision means double rounding).

> ABI you'd introduce x87 <-> SSE register moves which are not helpful
> for performance.

As I understand it, whether -mfpmath=387 (with excess precision) or 
-mfpmath=sse is the default is also considered part of the platform API 
(like whether char is signed or unsigned by default, for example), in 
addition to the ABI issues that can slow things down when SSE is used.

If people really want a new 32-bit x86 ABI I'd suggest making it an ILP32 
ABI for processors running in 64-bit mode, so 64-bit registers are 
available without the additional memory cost of 64-bit pointers for code 
not needing them - you could also assume a minimum of -march=x86-64, which 
implies SSE2.  But if there were significant demand for such an ABI I 
think we'd have seen it by now, and you probably run into the various 
syscall interface problems that MIPS n32 has had.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Change x86 default arch for 4.5?

[Geert Bosch]

On Feb 21, 2010, at 09:58, Joseph S. Myers wrote:
> On Sun, 21 Feb 2010, Richard Guenther wrote:
>>> The biggest change we need to make for x86 is to enable SSE2,
>>> so we can get proper rounding behavior for float and double,
>>> as well as significant performance increases.
>> 
>> I think Joseph fixed the rounding behavior for 4.5.  Also without an adjusted
> 
> Well, I provided the option for rounding that is predictable and in 
> accordance with C99 when using the default -mfpmath=387.  But that option 
> does carry the performance cost of storing to / loading from memory at 
> various points, as required to get the rounding on 387 (and there are 
> still cases where excess precision means double rounding).

This clearly is worse in all areas than using SSE2: there STILL is
double rounding, and performance goes down the drain. On any recent
machine there is the SSE2 hardware to do the operations correctly
without going through memory and without double rounding.

>> ABI you'd introduce x87 <-> SSE register moves which are not helpful
>> for performance.
> 
> As I understand it, whether -mfpmath=387 (with excess precision) or 
> -mfpmath=sse is the default is also considered part of the platform API 
> (like whether char is signed or unsigned by default, for example), in 
> addition to the ABI issues that can slow things down when SSE is used.

No, this is not a new ABI. The ABI stays exactly the same. The I of
ABI stands for Interface. That is, the ABI has nothing to say about
how a function will compute any results. That is the area of language
standards. The only way we'd violate the ABI is the reliance on SSE2
instructions being available and SSE2 registers being saved by the OS.

However, since any other compiler uses SSE2 instructions by default,
I don't see why GCC should be any different. If anything, since the
GCC target audience is more focused on Free and open source software,
we could be more aggressive in taking advantage of newer hardware.
What about an autoconf test for availability of 486 atomic instructions,
and SSE2 instructions in order, and choosing the default target based
on the host? Not too crazy, is it?

> If people really want a new 32-bit x86 ABI I'd suggest making it an ILP32 
> ABI for processors running in 64-bit mode, so 64-bit registers are 
> available without the additional memory cost of 64-bit pointers for code 
> not needing them - you could also assume a minimum of -march=x86-64, which 
> implies SSE2.  But if there were significant demand for such an ABI I 
> think we'd have seen it by now, and you probably run into the various 
> syscall interface problems that MIPS n32 has had.

Let's keep that can of worms closed, has nothing to do with changing
our -march defaults.

  -Geert

PS. If anyone has SPEC-like figures for performance difference between -msse2
    -mfpmath=sse,x87  and default, I'd be interested in seeing those results.

Re: Change x86 default arch for 4.5?

[H.J. Lu]

On Sun, Feb 21, 2010 at 6:58 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Sun, 21 Feb 2010, Richard Guenther wrote:
>
>> > The biggest change we need to make for x86 is to enable SSE2,
>> > so we can get proper rounding behavior for float and double,
>> > as well as significant performance increases.
>>
>> I think Joseph fixed the rounding behavior for 4.5.  Also without an adjusted
>
> Well, I provided the option for rounding that is predictable and in
> accordance with C99 when using the default -mfpmath=387.  But that option
> does carry the performance cost of storing to / loading from memory at
> various points, as required to get the rounding on 387 (and there are
> still cases where excess precision means double rounding).
>

I think your C99 change caused a regression on ia32:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128#c10

-- 
H.J.

Re: Change x86 default arch for 4.5?

[H.J. Lu]

On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch <bosch@adacore.com> wrote:

>> As I understand it, whether -mfpmath=387 (with excess precision) or
>> -mfpmath=sse is the default is also considered part of the platform API
>> (like whether char is signed or unsigned by default, for example), in
>> addition to the ABI issues that can slow things down when SSE is used.
>
> No, this is not a new ABI. The ABI stays exactly the same. The I of
> ABI stands for Interface. That is, the ABI has nothing to say about
> how a function will compute any results. That is the area of language
> standards. The only way we'd violate the ABI is the reliance on SSE2
> instructions being available and SSE2 registers being saved by the OS.
>
> However, since any other compiler uses SSE2 instructions by default,
> I don't see why GCC should be any different. If anything, since the
> GCC target audience is more focused on Free and open source software,
> we could be more aggressive in taking advantage of newer hardware.
> What about an autoconf test for availability of 486 atomic instructions,
> and SSE2 instructions in order, and choosing the default target based
> on the host? Not too crazy, is it?
>

I agreed that gcc for x86 should choose a sensible default for 95% of
current x86 processors in use. People with those old processors can
use older gcc or -march=.

Default to SSE2 is a good first step.


-- 
H.J.

Re: Change x86 default arch for 4.5?

[Richard Guenther]

On Sun, Feb 21, 2010 at 6:15 PM, Geert Bosch <bosch@adacore.com> wrote:
>
> On Feb 21, 2010, at 09:58, Joseph S. Myers wrote:
>> On Sun, 21 Feb 2010, Richard Guenther wrote:
>>>> The biggest change we need to make for x86 is to enable SSE2,
>>>> so we can get proper rounding behavior for float and double,
>>>> as well as significant performance increases.
>>>
>>> I think Joseph fixed the rounding behavior for 4.5.  Also without an adjusted
>>
>> Well, I provided the option for rounding that is predictable and in
>> accordance with C99 when using the default -mfpmath=387.  But that option
>> does carry the performance cost of storing to / loading from memory at
>> various points, as required to get the rounding on 387 (and there are
>> still cases where excess precision means double rounding).
>
> This clearly is worse in all areas than using SSE2: there STILL is
> double rounding, and performance goes down the drain. On any recent
> machine there is the SSE2 hardware to do the operations correctly
> without going through memory and without double rounding.
>
>>> ABI you'd introduce x87 <-> SSE register moves which are not helpful
>>> for performance.
>>
>> As I understand it, whether -mfpmath=387 (with excess precision) or
>> -mfpmath=sse is the default is also considered part of the platform API
>> (like whether char is signed or unsigned by default, for example), in
>> addition to the ABI issues that can slow things down when SSE is used.
>
> No, this is not a new ABI. The ABI stays exactly the same. The I of
> ABI stands for Interface. That is, the ABI has nothing to say about
> how a function will compute any results. That is the area of language
> standards. The only way we'd violate the ABI is the reliance on SSE2
> instructions being available and SSE2 registers being saved by the OS.
>
> However, since any other compiler uses SSE2 instructions by default,
> I don't see why GCC should be any different. If anything, since the
> GCC target audience is more focused on Free and open source software,
> we could be more aggressive in taking advantage of newer hardware.
> What about an autoconf test for availability of 486 atomic instructions,
> and SSE2 instructions in order, and choosing the default target based
> on the host? Not too crazy, is it?
>
>> If people really want a new 32-bit x86 ABI I'd suggest making it an ILP32
>> ABI for processors running in 64-bit mode, so 64-bit registers are
>> available without the additional memory cost of 64-bit pointers for code
>> not needing them - you could also assume a minimum of -march=x86-64, which
>> implies SSE2.  But if there were significant demand for such an ABI I
>> think we'd have seen it by now, and you probably run into the various
>> syscall interface problems that MIPS n32 has had.
>
> Let's keep that can of worms closed, has nothing to do with changing
> our -march defaults.
>
>  -Geert
>
> PS. If anyone has SPEC-like figures for performance difference between -msse2
>    -mfpmath=sse,x87  and default, I'd be interested in seeing those results.

http://gcc.opensuse.org/SPEC/CFP/sb-frescobaldi.suse.de-head-64-32o-32bit/recent.html
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/recent.html

note that SSE is still used by the vectorizer in both base/peak due to
-march=native.

Richard.

Re: Change x86 default arch for 4.5?

[Joseph S. Myers]

On Sun, 21 Feb 2010, Geert Bosch wrote:

> > As I understand it, whether -mfpmath=387 (with excess precision) or 
> > -mfpmath=sse is the default is also considered part of the platform API 
> > (like whether char is signed or unsigned by default, for example), in 
> > addition to the ABI issues that can slow things down when SSE is used.
> 
> No, this is not a new ABI. The ABI stays exactly the same. The I of

Correct - I said API, not ABI.  The API for C programs on x86 GNU/Linux 
involves FLT_EVAL_METHOD == 2, whereas that on x86 Darwin involves 
FLT_EVAL_METHOD == 0 and that on FreeBSD involves FLT_EVAL_METHOD == 2 
but with FPU rounding precision set to 53 bits so only excess range, not 
precision, applies.

You can support multiple APIs within one ABI - you can support both 
versions of -mfpmath just as you can support both signed and unsigned 
char, or both signed and unsigned bit-fields.  It is not however 
appropriate for -march options (whether explicit, or configured defaults 
from the noncanonical target name or otherwise) to change either ABI or 
API.  Configure options to configure with a different API would be fine, 
as would target names such as i686-pc-linux-gnussemath.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Change x86 default arch for 4.5?

[Richard Guenther]

On Sun, Feb 21, 2010 at 6:34 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Sun, 21 Feb 2010, Geert Bosch wrote:
>
>> > As I understand it, whether -mfpmath=387 (with excess precision) or
>> > -mfpmath=sse is the default is also considered part of the platform API
>> > (like whether char is signed or unsigned by default, for example), in
>> > addition to the ABI issues that can slow things down when SSE is used.
>>
>> No, this is not a new ABI. The ABI stays exactly the same. The I of
>
> Correct - I said API, not ABI.  The API for C programs on x86 GNU/Linux
> involves FLT_EVAL_METHOD == 2, whereas that on x86 Darwin involves
> FLT_EVAL_METHOD == 0 and that on FreeBSD involves FLT_EVAL_METHOD == 2
> but with FPU rounding precision set to 53 bits so only excess range, not
> precision, applies.
>
> You can support multiple APIs within one ABI - you can support both
> versions of -mfpmath just as you can support both signed and unsigned
> char, or both signed and unsigned bit-fields.  It is not however
> appropriate for -march options (whether explicit, or configured defaults
> from the noncanonical target name or otherwise) to change either ABI or
> API.  Configure options to configure with a different API would be fine,
> as would target names such as i686-pc-linux-gnussemath.

We could very well enable -mfpmath=sse as a side-effect of -ffast-math though.

Richard.

Re: Change x86 default arch for 4.5?

[Joseph S. Myers]

On Sun, 21 Feb 2010, Richard Guenther wrote:

> We could very well enable -mfpmath=sse as a side-effect of -ffast-math though.

Yes, or sse+387 if that helps.  As documented:

  @option{-fexcess-precision=standard} is not implemented for languages
  other than C, and has no effect if
  @option{-funsafe-math-optimizations} or @option{-ffast-math} is
  specified.  On the x86, it also has no effect if @option{-mfpmath=sse}
  or @option{-mfpmath=sse+387} is specified; in the former case, IEEE
  semantics apply without excess precision, and in the latter, rounding
  is unpredictable.

-funsafe-math-optimizations is expected to have sufficient effects on 
floating-point results that they can no longer be said to follow a 
particular API as regards excess precision, and so whichever API is 
fastest can be used.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Change x86 default arch for 4.5?

[Dave Korn]

On 21/02/2010 11:21, Paolo Carlini wrote:
> On 02/19/2010 01:46 AM, Joseph S. Myers wrote:
>> On Thu, 18 Feb 2010, Jason Merrill wrote:
>>   
>>> I periodically get bitten by bug 34115: a compiler configured without
>>> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we would
>>> only need to bump the default to i486 to get atomic support.  Can we
>>> reconsider the default for 4.5?
>>>     
>> My position remains that configuring for i686-* should default to 
>> -march=i686 rather than -mtune=i686.
>>
>> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html
>> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html
>>
>> Perhaps someone would like to review HJ's patch to that effect?
>>   
> Yes, please: for the record, I totally support this position.
> 
> Paolo.

  Likewise, I was very surprised when I found out that this wasn't already how
configure worked.  It makes perfect sense that configuring for i686-*-* should
get you an i686 compiler and configuring for i586-*-* should get you an i586
compiler and so on, rather than that you get an i386 compiler no matter what
you asked for.

  It seems a no-brainer that the default should match the target name that is
embedded into the compiler executable itself, so that it "does what it says on
the tin" (I'm all in favour of accuracy in labelling!), and since you can
always override the default with explicit command-line options, no generality
is lost.

    cheers,
      DaveK

Re: Change x86 default arch for 4.5?

[Martin Guy]

I disagree with the "default cpu should 95% of what is currently on
sale" argument.

The default affects naive users most strongly, so it should "just
work" on as many processors as is reasonable, not be as fast as
possible on most of the majority of the processors currently on sale.
Naive users might have anything.

As an example of the results of that kind of thinking, we've had years
of pain and wasted time in the ARM world due to the default
architecture being armv5t instead of armv4t. The results are that user
after user, making their first steps compiling a cross toolchain,
turns up on the mailing lists having got "illegal instruction" after
days of work, and that almost all the distributions are forced to
carry an "unbreak armv4t" patch to GCC.
Lord, someone was even compelled to try and get Android working on
their Openmoko, while it was binary-only, by emulating the few trivial
instructions in the kernel. Ubuntu, similarly, excludes the lower end
by leaving the default unchanged.

When users get interested in maximal speed, the first thing they do is
go for -mcpu=xyz, which doesn't require them to recompile the compiler
and is educational, while software distributions who build their own
compilers make their own choices about the minimum processors they
want to support.

Of course, most GCC developers and 95% of the people they know
probably do all have big new PCs using processors that are currently
in production, so to their eyes it might seem that all the world has
SSE2. However most people in the world cherish anything that works at
all; why make life harder for them?

We don't see the bottom end in the various usage stats because most
people using them don't have the internet (or a landline phone, come
to that).
The time-honoured policy of having the default settings work on as
wide a range hardware as possible is a socially inclusive one.
Some manifestos chisel the "low bar" into their constitutions (Debian
for example); it would be nice for GCC to do so too.

Cheers

    M

"You can't buy a computer these days with less that a gigabyte."
   -- A.S.Tanenbaum, trying to defend Minix's fixed-size kernel arrays
at FOSDEM 2010

Re: Change x86 default arch for 4.5?

[Martin Guy]

On 2/21/10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote:
>  It makes perfect sense that configuring for i686-*-* should
>  get you an i686 compiler and configuring for i586-*-* should get you an i586
>  compiler and so on, rather than that you get an i386 compiler no matter what
>  you asked for.

Agreed

   M

Re: Change x86 default arch for 4.5?

[Steven Bosscher]

On Sun, Feb 21, 2010 at 7:25 PM, Martin Guy <martinwguy@gmail.com> wrote:
> I disagree with the "default cpu should 95% of what is currently on
> sale" argument.
>
> The default affects naive users most strongly, so it should "just
> work" on as many processors as is reasonable, not be as fast as
> possible on most of the majority of the processors currently on sale.
> Naive users might have anything.

It is interesting how this conflicts with your signature:


> "You can't buy a computer these days with less that a gigabyte."
>   -- A.S.Tanenbaum, trying to defend Minix's fixed-size kernel arrays
> at FOSDEM 2010

I take it you disagree with this? Because most people do not expect to
need 1GB for a Minix installation. ;-)

Anyway, naive users also expect reasonable performance, which they
don't get with the existing defaults [*]. And there are far many more
default naive users who have systems with CPUs of designs less than 5
years old. You want to cater for a minority with old hardware. I
actually expect you'll find that those users are less naive than the
average gcc user.

([*] I sometimes even have to explain -O2, because icc has
optimizations on by default. Many Fortran users do not use gfortran
because they don't know about this difference...)

> As an example of the results of that kind of thinking, we've had years
> of pain and wasted time in the ARM world due to the default
> architecture being armv5t instead of armv4t. The results are that user
> after user, making their first steps compiling a cross toolchain,
> turns up on the mailing lists having got "illegal instruction" after
> days of work, and that almost all the distributions are forced to
> carry an "unbreak armv4t" patch to GCC.

Can you name these distributions? I can only name Debian
(http://lists.debian.org/debian-arm/2006/06/msg00015.html)

> Lord, someone was even compelled to try and get Android working on
> their Openmoko, while it was binary-only, by emulating the few trivial
> instructions in the kernel. Ubuntu, similarly, excludes the lower end
> by leaving the default unchanged.

Ubuntu also requires i686 or later. As do most other Linux distributions.

But anyway, bringing ARM into this discussion is neither here nor there.


> When users get interested in maximal speed, the first thing they do is
> go for -mcpu=xyz

Your naive users (and mine) don't even know about -mcpu and -march.


>, which doesn't require them to recompile the compiler

Neither does compiling for i386/i486 or armv4 if you have a
cross-compiler for another default -- you can use -mcpu to "downgrade"
too.


> The time-honoured policy of having the default settings work on as
> wide a range hardware as possible is a socially inclusive one.
> Some manifestos chisel the "low bar" into their constitutions (Debian
> for example); it would be nice for GCC to do so too.

You're off it with the "socially inclusive" argument. No-one is
excluded at all, if the defaults are changed. The only thing that
happens is that the small number of users with exceptional
configurations get the burden of dealing with the -march/-mtune
options.
(**/me mumbles something incoherent about Pareto, etc...***)

Ciao!
Steven

Re: Change x86 default arch for 4.5?

[Dave Korn]

On 21/02/2010 19:09, Steven Bosscher wrote:
> On Sun, Feb 21, 2010 at 7:25 PM, Martin Guy <martinwguy@gmail> wrote:

>> As an example of the results of that kind of thinking, we've had years
>> of pain and wasted time in the ARM world due to the default
>> architecture being armv5t instead of armv4t. The results are that user
>> after user, making their first steps compiling a cross toolchain,
>> turns up on the mailing lists having got "illegal instruction" after
>> days of work, and that almost all the distributions are forced to
>> carry an "unbreak armv4t" patch to GCC.

> But anyway, bringing ARM into this discussion is neither here nor there.

  Except inasmuch as that the proposed fix for i?86 could be extended with
similar behaviour for arm and then people could set the default by using the
right cpu name in the --target setting and it would solve this problem too.

>> The time-honoured policy of having the default settings work on as
>> wide a range hardware as possible is a socially inclusive one.
>> Some manifestos chisel the "low bar" into their constitutions (Debian
>> for example); it would be nice for GCC to do so too.
> 
> You're off it with the "socially inclusive" argument. No-one is
> excluded at all, if the defaults are changed. The only thing that
> happens is that the small number of users with exceptional
> configurations get the burden of dealing with the -march/-mtune
> options.

  I too am having a hard time envisaging exactly who would be in this class of
users who are simultaneously so naive that they don't know about -march or
-mcpu or think to read the manual, and yet so advanced that they are trying to
write programs for and rebuild modern compilers on ancient equipment....

    cheers,
      DaveK

Re: Change x86 default arch for 4.5?

[Martin Guy]

On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote:

> It is interesting how this conflicts with your signature:
>  > "You can't buy a computer these days with less that a gigabyte."
>  >   -- A.S.Tanenbaum, trying to defend Minix's fixed-size kernel arrays
>  > at FOSDEM 2010
> I take it you disagree with this? Because most people do not expect to
>  need 1GB for a Minix installation. ;-)
It's a straw man, another example of bogus reasoning. Of course you
can buy new computers with 64MB, and they are particularly suitable
for simple kernels.
The embedded Linux/BSD crowd at the presentation didn't seem very
impressed either.

> You want to cater for a minority with old hardware. I
>  actually expect you'll find that those users are less naive than the
>  average gcc user.
I want to cater for everyone, especially youngsters, learners and the
poor struggling with whatever they can get their hands on.
It's not even a rich country/poor country thing: I live in a run down
industrial area of England where the local kids are gagging for
anything that works.

> Can you name these distributions? I can only name Debian
>  (http://lists.debian.org/debian-arm/2006/06/msg00015.html)
A quick search for "unbreak-armv4t.patch" shows, at a glance on the
first ten hits, fedora, openembedded, slind, openmoko, mamona,
android-porting. I'll leave you to peruse page two on :)

> Ubuntu also requires i686 or later.
Ubuntu also needs 384MB to work these days, so it is a reasonable
application-specific choice for that distro. GCC should not be
tailored to high-end desktop, laptop and server machines.

>  But anyway, bringing ARM into this discussion is neither here nor there.
It is a specific example of a pointlessly higher cpu default (for
"arm-*") where such a decision was made in GCC and the annoyances it
causes. which is what this thread had drifted into.

> Your naive users (and mine) don't even know about -mcpu and -march.
Exactly, so they go "cc hello.c; a.out" and get "Illegal instruction"
unless they have a relatively new first-world PC.

>  >, which doesn't require them to recompile the compiler
> Neither does compiling for i386/i486 or armv4 if you have a
>  cross-compiler for another default -- you can use -mcpu to "downgrade"
>  too.
Of course. However it does bite cross-compilers because people end up
distributing the C library compiled for a high-end CPU, so no program
will run even when you do drop the -mcpu level. Raising it instead
still works for everyone.

>  (**/me mumbles something incoherent about Pareto, etc...***)
Moore's Law suggests that we should optimise most intensely for the
physically slower processors, where sloth or speed translates into
more real time, but I forgot that point in the last post :)

Actually, this is irrelevant to the thread, since one always has to
specify a CPU model in the tuple when configuring for i?86, and the
thread was about an i686-* configuration tuple still producing a
compiler that outputs i386 code by default, which does seem silly.

Happy Sunday.

   M

Re: Change x86 default arch for 4.5?

[Martin Guy]

On 2/21/10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote:
>   I too am having a hard time envisaging exactly who would be in this class of
>  users who are simultaneously so naive that they don't know about -march or
>  -mcpu or think to read the manual, and yet so advanced that they are trying to
>  write programs for and rebuild modern compilers on ancient equipment....

Old equipment is retro in rich places, but we built the first
public-access email lab from stuff found in skips in inner-city Sicily
and were very glad that Slackware, Debian and so on ran on 386 and
486's. At that time "everyone who was anyone" had pentium MMXs at
least.

The point about defaults is that the GCC default tends to filter down
into the default for distributions; if GCC had been following the "90%
of people have Pentiums" rule, and the distros followed the default,
our low-budget lab would have been two terminals instead of about a
dozen (or had to run SCO Xenix or something). I'm ex-UK-university
computing lecturer myself, but been both rich and poor, both many
times, so I know how the other half lives.

Incidentally, one of the hackers who used Linux in that Sicilian squat
at the age of 13 has just been accepted to do a computing degree at
Cambridge University, UK.

Not this this *still* has anything to do with the thread, but it's Sunday, so...

Bless

   M

Re: Change x86 default arch for 4.5?

[Dave Korn]

On 21/02/2010 19:45, Martin Guy wrote:
> On 2/21/10, Steven Bosscher <stevenb.gcc@gmail> wrote:

>> Your naive users (and mine) don't even know about -mcpu and -march.
> Exactly, so they go "cc hello.c; a.out" and get "Illegal instruction"
> unless they have a relatively new first-world PC.

  So learning to program is difficult.  I don't think any compiler default
commandline setting can change that, but on the brights side, learning about
commandline options is pretty much the first thing any newbie will need to
learn in order to drive a compiler.

> Of course. However it does bite cross-compilers because people end up
> distributing the C library compiled for a high-end CPU, so no program
> will run even when you do drop the -mcpu level. 

  What do these people think they are doing posing as distributors without
knowing the first thing about packaging and binary distribution?

> Actually, this is irrelevant to the thread, since one always has to
> specify a CPU model in the tuple when configuring for i?86, and the
> thread was about an i686-* configuration tuple still producing a
> compiler that outputs i386 code by default, which does seem silly.

  A quick browse through config.gcc suggests most of the arm targets match the
"arm*-*-<something>" pattern, so it might be quite easy to adopt the same
use-the-precise-cpu-model-in-the-target-triplet scheme for ARM, mightn't it?
(Though obviously with the proviso of making it actually work, as proposed but
not yet implemented for x86!)

    cheers,
      DaveK

Re: Change x86 default arch for 4.5?

[Joe Buck]

On Sun, Feb 21, 2010 at 11:45:49AM -0800, Martin Guy wrote:
> > You want to cater for a minority with old hardware. I
> >  actually expect you'll find that those users are less naive than the
> >  average gcc user.
> I want to cater for everyone, especially youngsters, learners and the
> poor struggling with whatever they can get their hands on.
> It's not even a rich country/poor country thing: I live in a run down
> industrial area of England where the local kids are gagging for
> anything that works.

Let's step back a bit and look at the tradeoffs.  I see two main
inflection points where the choice of default has a real impact.

First, you have to assume i486 if you want a libstdc++ that supports
locking correctly.  If you default to i386, you screw every user of an
i486-or-later processor by giving them locking that doesn't work, for the
benefit of a processor that hasn't been manufactured in several years, and
was only used in embedded markets for a number of years before that.  To
me, that's a no-brainer; we should assume 486 and ask the tiny minority
trying to make an ancient system work to use the appropriate switches.
Right now, GNU/Linux distros are already doing that.

The second inflection point is being able to assume enough SSE to
generate improved floating point.  Here, it seems less clear that
it's better to change the default, as it's more possible that the
users of older systems that you champion could be impacted.

Re: Change x86 default arch for 4.5?

[Erik Trulsson]

On Sun, Feb 21, 2010 at 09:27:13AM -0800, H.J. Lu wrote:
> On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch <bosch@adacore.com> wrote:
> 
> >> As I understand it, whether -mfpmath=387 (with excess precision) or
> >> -mfpmath=sse is the default is also considered part of the platform API
> >> (like whether char is signed or unsigned by default, for example), in
> >> addition to the ABI issues that can slow things down when SSE is used.
> >
> > No, this is not a new ABI. The ABI stays exactly the same. The I of
> > ABI stands for Interface. That is, the ABI has nothing to say about
> > how a function will compute any results. That is the area of language
> > standards. The only way we'd violate the ABI is the reliance on SSE2
> > instructions being available and SSE2 registers being saved by the OS.
> >
> > However, since any other compiler uses SSE2 instructions by default,
> > I don't see why GCC should be any different. If anything, since the
> > GCC target audience is more focused on Free and open source software,
> > we could be more aggressive in taking advantage of newer hardware.

One of the great advantages of much free/open software is the way it
will work just fine even on older hardware.

> > What about an autoconf test for availability of 486 atomic instructions,
> > and SSE2 instructions in order, and choosing the default target based
> > on the host? Not too crazy, is it?

Actually that is too crazy.  Assuming that the binaries produced by any
given compiler installation will only be used on the machine the
compiler runs on is not a safe assumption.


> >
> 
> I agreed that gcc for x86 should choose a sensible default for 95% of
> current x86 processors in use. People with those old processors can
> use older gcc or -march=.
> 
> Default to SSE2 is a good first step.

I think you vastly underestimate the number of older x86 processors in
use.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: Change x86 default arch for 4.5?

[Dave Korn]

On 21/02/2010 20:03, Martin Guy wrote:

> The point about defaults is that the GCC default tends to filter down
> into the default for distributions; 

  I'd find it surprising if that was really the way it happens; don't
distributions make deliberate and conscious decisions about binary standards
and things like that?  They certainly ought to be doing so, IMO, rather than
just going with whatever-the-compiler-does-when-you-don't-tell-it-what-to-do.

    cheers,
      DaveK

Re: Change x86 default arch for 4.5?

[H.J. Lu]

On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
>>
>> I agreed that gcc for x86 should choose a sensible default for 95% of
>> current x86 processors in use. People with those old processors can
>> use older gcc or -march=.
>>
>> Default to SSE2 is a good first step.
>
> I think you vastly underestimate the number of older x86 processors in
> use.
>

There is nothing which stops them from using -march=i386. It just may not
be the default.


-- 
H.J.

Re: Change x86 default arch for 4.5?

[Laurent GUERBY]

On Sun, 2010-02-21 at 20:44 +0000, Dave Korn wrote:
> On 21/02/2010 20:03, Martin Guy wrote:
> 
> > The point about defaults is that the GCC default tends to filter down
> > into the default for distributions; 
> 
>   I'd find it surprising if that was really the way it happens; don't
> distributions make deliberate and conscious decisions about binary standards
> and things like that?  They certainly ought to be doing so, IMO, rather than
> just going with whatever-the-compiler-does-when-you-don't-tell-it-what-to-do.

Distributions do tweak to meet their goals: for example nearly all
distributions ship with Ada enabled whereas GCC configure defaults with
Ada disabled even when an Ada compiler is available to bootstrap with.

Debian on mips (currently) defaults to o32 whereas GCC configure
defaults to n32. I assume there are many other examples.

Laurent

Re: Change x86 default arch for 4.5?

[Erik Trulsson]

On Sun, Feb 21, 2010 at 12:27:34PM -0800, H.J. Lu wrote:
> On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
> >>
> >> I agreed that gcc for x86 should choose a sensible default for 95% of
> >> current x86 processors in use. People with those old processors can
> >> use older gcc or -march=.
> >>
> >> Default to SSE2 is a good first step.
> >
> > I think you vastly underestimate the number of older x86 processors in
> > use.
> >
> 
> There is nothing which stops them from using -march=i386. It just may not
> be the default.

That argument cuts both ways you know.  There is nothing stopping
people with the latest CPUs from using -march=  to get code optimised
for their hardware.  It just may not be the default.



 


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: Change x86 default arch for 4.5?

[Steven Bosscher]

On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
> One of the great advantages of much free/open software is the way it
> will work just fine even on older hardware.

Yes, but that doesn't change if the compiler changes the default
target processor.

And, let's face it, most users of gcc don't use it because it is free
software but because it performs just fine for them. And when it does
not, they just as easily switch to another compiler.

To be competitive with alternatives, is why, IMHO, gcc should target
newer processors. Because "the other guys" are doing it also, and it
hurts the gcc user base if gcc chooses to lag behind.

> I think you vastly underestimate the number of older x86 processors in
> use.

Yes, of course -- but what is the advantage of using the latest GCC
for such an older processor? This is something no-one has ever been
able to explain to me (I've asked before). I can give some
disadvantages, though.

The newer compilers usually add nothing much more than support for the
newer processors and their new instruction sets, and newer compilers
tend to be tuned for newer processors too (simply because the
developers work with newer boxes). An older compiler will be no worse
than a newer compiler for those older processors -- probably sometimes
even better.

Ciao!
Steven

Re: Change x86 default arch for 4.5?

[H.J. Lu]

On Sun, Feb 21, 2010 at 1:07 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
> On Sun, Feb 21, 2010 at 12:27:34PM -0800, H.J. Lu wrote:
>> On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
>> >>
>> >> I agreed that gcc for x86 should choose a sensible default for 95% of
>> >> current x86 processors in use. People with those old processors can
>> >> use older gcc or -march=.
>> >>
>> >> Default to SSE2 is a good first step.
>> >
>> > I think you vastly underestimate the number of older x86 processors in
>> > use.
>> >
>>
>> There is nothing which stops them from using -march=i386. It just may not
>> be the default.
>
> That argument cuts both ways you know.  There is nothing stopping
> people with the latest CPUs from using -march=  to get code optimised
> for their hardware.  It just may not be the default.

That is where majority comes in.

-- 
H.J.

Re: Change x86 default arch for 4.5?

[Steven Bosscher]

On Sun, Feb 21, 2010 at 9:44 PM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> On 21/02/2010 20:03, Martin Guy wrote:
>
>> The point about defaults is that the GCC default tends to filter down
>> into the default for distributions;
>
>  I'd find it surprising if that was really the way it happens; don't
> distributions make deliberate and conscious decisions about binary standards
> and things like that?  They certainly ought to be doing so, IMO, rather than
> just going with whatever-the-compiler-does-when-you-don't-tell-it-what-to-do.

Well, as Martin already pointed out (contradicting his own point):
Apparently a lot of distributions *do* change the defaults, see armv4t
discussion.

Ciao!
Steven

Re: Change x86 default arch for 4.5?

[Steven Bosscher]

On Sun, Feb 21, 2010 at 10:07 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
>> There is nothing which stops them from using -march=i386. It just may not
>> be the default.
>
> That argument cuts both ways you know.  There is nothing stopping
> people with the latest CPUs from using -march=  to get code optimised
> for their hardware.  It just may not be the default.

Which brings us back to the discussion of satisfying the needs of a
tiny minority while hurting the vast majority of users. I prefer to
satisfy the need of the majority.

Ciao!
Steven

Re: Change x86 default arch for 4.5?

[H.J. Lu]

On Sun, Feb 21, 2010 at 9:27 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch <bosch@adacore.com> wrote:
>
>>> As I understand it, whether -mfpmath=387 (with excess precision) or
>>> -mfpmath=sse is the default is also considered part of the platform API
>>> (like whether char is signed or unsigned by default, for example), in
>>> addition to the ABI issues that can slow things down when SSE is used.
>>
>> No, this is not a new ABI. The ABI stays exactly the same. The I of
>> ABI stands for Interface. That is, the ABI has nothing to say about
>> how a function will compute any results. That is the area of language
>> standards. The only way we'd violate the ABI is the reliance on SSE2
>> instructions being available and SSE2 registers being saved by the OS.
>>
>> However, since any other compiler uses SSE2 instructions by default,
>> I don't see why GCC should be any different. If anything, since the
>> GCC target audience is more focused on Free and open source software,
>> we could be more aggressive in taking advantage of newer hardware.
>> What about an autoconf test for availability of 486 atomic instructions,
>> and SSE2 instructions in order, and choosing the default target based
>> on the host? Not too crazy, is it?
>>
>
> I agreed that gcc for x86 should choose a sensible default for 95% of
> current x86 processors in use. People with those old processors can
> use older gcc or -march=.
>
> Default to SSE2 is a good first step.
>

FWIW, here is a patch to add --with-math=sse for x86:

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00714.html


-- 
H.J.

Re: Change x86 default arch for 4.5?

[Dave Korn]

On 21/02/2010 21:53, Steven Bosscher wrote:

> Yes, of course -- but what is the advantage of using the latest GCC
> for such an older processor? 

  Tree-SSA?  LTO?  Fixed bugs?  New languages?  Etc?  I can see plenty of good
reasons for it.

> The newer compilers usually add nothing much more than support for the
> newer processors and their new instruction sets, 

  That doesn't sound like any GCC that I'm familiar with!

    cheers,
      DaveK

Re: Change x86 default arch for 4.5?

[Erik Trulsson]

On Sun, Feb 21, 2010 at 10:53:54PM +0100, Steven Bosscher wrote:
> On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
> > One of the great advantages of much free/open software is the way it
> > will work just fine even on older hardware.
> 
> Yes, but that doesn't change if the compiler changes the default
> target processor.

Yes, it does if the user is using binaries compiled by somebody else,
and that somebody else did not explicitly specify any CPU-flags.

I believe that is the situation when installing most
Linux-distributions for example.


> 
> And, let's face it, most users of gcc don't use it because it is free
> software but because it performs just fine for them. And when it does
> not, they just as easily switch to another compiler.

No, most users of gcc use it beacause it is the default compiler that
came with the system they are using.  
Switching to another compiler is not always as easy as it might be.

> 
> To be competitive with alternatives, is why, IMHO, gcc should target
> newer processors. Because "the other guys" are doing it also, and it
> hurts the gcc user base if gcc chooses to lag behind.

Considering that most code will not run noticably faster just because
you optimize it for the newest CPU, the majority of the user base are
not hurt at all.

> 
> > I think you vastly underestimate the number of older x86 processors in
> > use.
> 
> Yes, of course -- but what is the advantage of using the latest GCC
> for such an older processor? This is something no-one has ever been
> able to explain to me (I've asked before). I can give some
> disadvantages, though.
> 
> The newer compilers usually add nothing much more than support for the
> newer processors and their new instruction sets, and newer compilers
> tend to be tuned for newer processors too (simply because the
> developers work with newer boxes). An older compiler will be no worse
> than a newer compiler for those older processors -- probably sometimes
> even better.

Newer compilers usually have better generic optimizations that are not
CPU-dependent.  Newer compilers also typically have improved support
for new language-features (and new languages for that matter.)
Newer compilers are often better at warning about dubious (or simply
wrong) code making it easier to find bugs in the code.

Plenty of reasons for using a newer compiler regardless of if your
target-CPU is new or old.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: Change x86 default arch for 4.5?

[Erik Trulsson]

On Sun, Feb 21, 2010 at 10:59:05PM +0100, Steven Bosscher wrote:
> On Sun, Feb 21, 2010 at 10:07 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
> >> There is nothing which stops them from using -march=i386. It just may not
> >> be the default.
> >
> > That argument cuts both ways you know.  There is nothing stopping
> > people with the latest CPUs from using -march=  to get code optimised
> > for their hardware.  It just may not be the default.
> 
> Which brings us back to the discussion of satisfying the needs of a
> tiny minority while hurting the vast majority of users. I prefer to
> satisfy the need of the majority.

That would depend on how large the majority is compared to the minority
and how much they will be hurt in the respective cases.

As for the relative sizes of the groups, the above comments were in
context of using SSE2 by default.  I do not believe that the vast
majority of x86 CPUs currently in use do support SSE2.  A majority of
them, possibly, but not a vast majority.

As for the relative hurts.  Code compiled for a newer CPU (making use
of newer instructions) will not run at all on older CPUs not supporting
those newer instructions.  Much hurt there.

On the other hand code compiled for an older CPU that is run a newer
CPU will run just fine, if slightly slower than they could have due to
not making use of new instructions in the newer CPU.
For most programs the performance increase of re-compiling for the
newer CPU would be barely noticable so the hurt of not having that is
very little.




-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: Change x86 default arch for 4.5?

[Dave Korn]

On 21/02/2010 22:42, Erik Trulsson wrote:

> Yes, it does if the user is using binaries compiled by somebody else,
> and that somebody else did not explicitly specify any CPU-flags.
> 
> I believe that is the situation when installing most
> Linux-distributions for example.

  No, surely not.  The linux distributions use configure options when they
package their compilers to choose the default with-cpu and with-arch options,
and those are quite deliberately chosen according to the binary standards of
the distro.  It is hardly a case of "somebody else did not explicitly specify"
cpu flags; they in fact explicitly specified them according to the system
requirements for the distro.  If your distro says it doesn't support i386,
this is *why*!

> Considering that most code will not run noticably faster just because
> you optimize it for the newest CPU, 

  Considering nobody is suggesting that, it is an irrelevant red herring.
We're talking about optimising for "any CPU built in the past five years" vs.
"any cpu built in the past twentyfive years"; not switching on some option
that will break code on any but the very latest models.

  You're also wrong about how much difference switching on SSE makes to real
applications.  Any application that isn't I/O bound but does a lot of
in-memory processing will run noticeably better, anything that uses loops or
stdlib string or memory copy/move functions, this is not some tiny minor tweak
we're looking at.

    cheers,
      DaveK

Re: Change x86 default arch for 4.5?

[Martin Guy]

On 2/21/10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote:
> On 21/02/2010 20:03, Martin Guy wrote:
>  > The point about defaults is that the GCC default tends to filter down
>  > into the default for distributions;
>   I'd find it surprising if that was really the way it happens; don't
>  distributions make deliberate and conscious decisions about binary standards
>  and things like that?

Changing the default without losing that compatability would assume
that every distro (and there are hundreds of them) either already
specifies a specific arch or that its GCC maintainer notices the
change in GCC and adds explicit configuration options to revert the
change. The big ones with dedicated maintainers for GCC probably
already do that; others just configure and make the standard distro
and take what comes.

On 2/21/10, H.J. Lu <hjl.tools@gmail.com> wrote:
> There is nothing which stops them from using -march=i386. It just may not
>  be the default.
There is: the arch that the libraries in their distro were compiled to run on.

On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
>  > One of the great advantages of much free/open software is the way it
>  > will work just fine even on older hardware.
>  And, let's face it, most users of gcc don't use it because it is free
>  software but because it performs just fine for them. And when it does
>  not, they just as easily switch to another compiler.
Hardly. At present there is a GCC monoculture, both in what is the
standard compiler with most systems and in what compiler packages will
build with, either because the build system uses GCC-specific flags or
because the code using GCC extensions.

On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> Which brings us back to the discussion of satisfying the needs of a
>  tiny minority while hurting the vast majority of users.
There's a difference in quality between the two. The "hurt" is that
powerful modern PCs might take 20% longer to encode a DVD, while the
"needs" is that the bulk of software will run at all on their poor
hardware.

It's usual in modern societies to give priority to enabling the
underprivileged to function at all over giving the well-off the
maximum of comfort and speed, but how you value the two aspects
probably depends on your personal experience of the two realities.

On 2/21/10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote:
> On 21/02/2010 21:53, Steven Bosscher wrote:
>  > Yes, of course -- but what is the advantage of using the latest GCC
>  > for such an older processor?
>   Tree-SSA?  LTO?  Fixed bugs?  New languages?  Etc?  I can see plenty of good
>  reasons for it.
Apart from those factors (and one hopes that in general all code
generation improves from release to release), users may not really
have a choice, being most likely to try (or be given) the most recent
stable version of whatever distro, and distros tend to try to ship the
most recent stable gcc in each new release.

Let me add another example from my own experience: In 2001 I was stuck
for months in a crumbling house in the countryside with nothing but an
8MB 25MHz 386 because that's all l I had available at the time (green
screen, yay!) and I completed what would have been my postgraduate
degree project, begun in 1985: an unlimited precision floating point
math library in a pure functional language. The fact that I could do
that at all may be due to GCC's "work on the minimum" policy of the
time, both in the distro and on whatever machine David Turner used to
compile the binary-only release of the Miranda interpreter.

If I recall correctly, the default is currently arched and tuned for
486, and the 386's lacks are trapped and emulated in the kernel.

On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> Well, as Martin already pointed out (contradicting his own point):
>  Apparently a lot of distributions *do* change the defaults.

That's OK, I don't have The Truth in my pocket. Nor do I have any
quantifiable measure of the number of different systems in use in the
whole world, just a value judgement based on a different set of
experiences of the outcome of restrictive and generous policies in
munimum CPU targetting, which I'm sharing.

My direct experience is that low-end PCs are widely used in societies
where things are hard, and that upstream software developers are
always given the latest, fastest computers to make them more
productive and are unaware of the struggling masses :)

Cheers

  M

Re: Change x86 default arch for 4.5?

[Steven Bosscher]

On Mon, Feb 22, 2010 at 12:28 AM, Martin Guy <martinwguy@gmail.com> wrote:
> On 2/21/10, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson <ertr1013@student.uu.se> wrote:
>>  > One of the great advantages of much free/open software is the way it
>>  > will work just fine even on older hardware.
>>  And, let's face it, most users of gcc don't use it because it is free
>>  software but because it performs just fine for them. And when it does
>>  not, they just as easily switch to another compiler.
> Hardly. At present there is a GCC monoculture, both in what is the
> standard compiler with most systems and in what compiler packages will
> build with, either because the build system uses GCC-specific flags or
> because the code using GCC extensions.

This is certainly true on most linux machines. But on non-linux
machines GCC is usually just another option.  And at least on
ix86-linux and x86_64 linux, it is very easy to install other
compilers. Most people I know who do software development, have at
least gcc and icc installed, and sometimes llvm and some proprietary
compilers (Absoft, Pathscale, etc.). This is probably because...

> (...) The "hurt" is that
> powerful modern PCs might take 20% longer to encode a DVD, while the
> "needs" is that the bulk of software will run at all on their poor
> hardware.

...this 20% costs a lot of money (time, energy (!), other resources)
if you do high-end computing. And in many cases, it is a lot more than
20%. The structural analysis code I worked with, runs about 2.5 times
faster if SSE2 and vectorization are enabled. Since this is an
interactive application, it saves money by keeping busy the otherwise
idly waiting engineers. The developers of this code were not aware of
the options you have to pass to GCC to get this win. Arguably that's
their problem, but I don't think so. They just chose the way of least
resistance: compare gcc and icc and take the fastest. The hurt is on
gcc, because it loses users.

For home machines: You should realize that if that DVD encodes 20%
faster, or that movie plays without flickering, or ... on Windows 7,
people switch. It is what users do: they find the machine+OS that
works best for them. I honestly believe it works like that. I see it
all around me, and I even still have a dual-boot installation because
of this.

If a change in the defaults of GCC helps proliferate free software
better (an FSF political goal, which are relevant, unlike political
views you've mentioned) then this change should be seriously
considered.


>>  > Yes, of course -- but what is the advantage of using the latest GCC
>>  > for such an older processor?
>>   Tree-SSA?  LTO?  Fixed bugs?  New languages?  Etc?  I can see plenty of good
>>  reasons for it.
> Apart from those factors (and one hopes that in general all code
> generation improves from release to release), users may not really
> have a choice, being most likely to try (or be given) the most recent
> stable version of whatever distro, and distros tend to try to ship the
> most recent stable gcc in each new release.

If these users try to run the latest distro/GCC on such older
hardware, it probably doesn't even work. Tree-SSA has increased the
resources required by GCC significantly. LTO will almost certainly not
work for any meaningful application on older hardware. The only new
languages in recent years in GCC are ObjC++, which nobody uses, and
Fortran 95, which nobody uses on old hardware (except perhaps for
educational purposes, but if you use Fortran then you probably have
access to better hardware than a 20 year old desktop).

Ciao!
Steven

Re: Change x86 default arch for 4.5?

[Erik Trulsson]

On Sun, Feb 21, 2010 at 11:35:11PM +0000, Dave Korn wrote:
> On 21/02/2010 22:42, Erik Trulsson wrote:
> 
> > Yes, it does if the user is using binaries compiled by somebody else,
> > and that somebody else did not explicitly specify any CPU-flags.
> > 
> > I believe that is the situation when installing most
> > Linux-distributions for example.
> 
>   No, surely not.  The linux distributions use configure options when they
> package their compilers to choose the default with-cpu and with-arch options,
> and those are quite deliberately chosen according to the binary standards of
> the distro.  It is hardly a case of "somebody else did not explicitly specify"
> cpu flags; they in fact explicitly specified them according to the system
> requirements for the distro.  If your distro says it doesn't support i386,
> this is *why*!

Are you sure of that?  Really sure?
Some Linux distributions almost certainly do as you describe, but all
of them?  I doubt it.


> 
> > Considering that most code will not run noticably faster just because
> > you optimize it for the newest CPU, 
> 
>   Considering nobody is suggesting that, it is an irrelevant red herring.
> We're talking about optimising for "any CPU built in the past five years" vs.
> "any cpu built in the past twentyfive years"; not switching on some option
> that will break code on any but the very latest models.

There certainly have been x86 CPUs built in the past five years that do
not support SSE, let alone SSE2.  

Besides, five years is not a very long time at all.  Not in this
context anyway.





> 
>   You're also wrong about how much difference switching on SSE makes to real
> applications.  Any application that isn't I/O bound but does a lot of
> in-memory processing will run noticeably better, anything that uses loops or
> stdlib string or memory copy/move functions, this is not some tiny minor tweak
> we're looking at.

I remain sceptical.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: Change x86 default arch for 4.5?

[Geert Bosch]

On Feb 21, 2010, at 17:42, Erik Trulsson wrote:
> Newer compilers usually have better generic optimizations that are not
> CPU-dependent.  Newer compilers also typically have improved support
> for new language-features (and new languages for that matter.)

This is exactly where CPU dependence comes into play. I'd like
for example take advantage of IEEE floating point semantics in
our Ada compiler. Fifteen years ago, we had to face the fact that
some systems were not compliant and therefore we developed
least-common-denominator libraries that catered to all.

However, nowadays even OpenVMS supports IEEE floating point.
I'd like to get rid of hacks in GNAT avoid relying on strict
IEEE compliance. Currently we end up doing some conversions
and computations in the widest floating-point type to avoid
double rounding.

So, I'd like to be able to put all this behind me, and only
have to think about fully IEEE compliant systems. Similarly,
there is no way to fully implement C99 Annex F without using
SSE2.

As a last point, because not many GCC users take advantage
of the hardware their systems have, there is less focus
and feedback on improving SSE2 code generation, vectorization 
and the like.

In conclusion, I think GCC is being held back by us sticking
to 20-year old hardware. For GCC to be the best compiler 
possible on current and future systems, we have to start
compiling for those systems by default.

This is essential for GCC's long term relevance.

  -Geert

Re: Change x86 default arch for 4.5?

[Geert Bosch]

On Feb 21, 2010, at 12:34, Joseph S. Myers wrote:

> Correct - I said API, not ABI.  The API for C programs on x86 GNU/Linux 
> involves FLT_EVAL_METHOD == 2, whereas that on x86 Darwin involves 
> FLT_EVAL_METHOD == 0 and that on FreeBSD involves FLT_EVAL_METHOD == 2 
> but with FPU rounding precision set to 53 bits so only excess range, not 
> precision, applies.

Your following paragraph "If people really want a new 32-bit x86 ABI..."
threw me off. Your message contained the word ABI 4 times, and API once.
I missed it, apologies.

However, I think this is a bit of a red herring. There
really is no consistent well-defined model for our current 
floating-point semantics on x86. Wether a value is computed with
extra precision or not depends on many factors, such as optimization.

The best way to describe the current situation is that any operation
may or may not keep excess precision or range. Your patch to incur 
more double rounding by going through memory more often does not 
really solve this issue, it will just make results a little more 
consistent, but possible also less accurate and less precise.

So, in short, we all will lose in a quest to support C99
on least common denominator hardware. We will not
be able to achieve full compliance, we will all have to 
deal with worse performance due to additional spilling. 
All at the same time any other compiler will
happily take advantage of the user's hardware and compile
great code that is faster and produces better results.

  -Geert

Re: Change x86 default arch for 4.5?

[Geert Bosch]

On Feb 21, 2010, at 07:13, Richard Guenther wrote:
> The present discussion is about defaulting to at least 486 when not
> configured for i386-linux.  That sounds entirely reasonable to me.

I fully agree with the "at least 486" part. However,
if we only change the default once every 20 years, it seems
we should bump it up more than to just 486...

People who compile GCC from sources, mostly use it to
compile other code from source for their own use.
The only reason to by default generate code for an
older chip than the one on the host, is to distribute
binaries. Why would a GNU compiler by default give
up performance and numerical stability to facilitate
binary distribution? 

Basically, GCC has to compete with other compilers,
such as those from Microsoft and Intel. When GCC 
arbitrarily decides to tie one hand behind its back,
so that code by default targets a 25-year-old
chip, it is no surprise it comes out looking bad.

  -Geert

Re: Change x86 default arch for 4.5?

[Joseph S. Myers]

On Sun, 21 Feb 2010, Geert Bosch wrote:

> On Feb 21, 2010, at 17:42, Erik Trulsson wrote:
> > Newer compilers usually have better generic optimizations that are not
> > CPU-dependent.  Newer compilers also typically have improved support
> > for new language-features (and new languages for that matter.)
> 
> This is exactly where CPU dependence comes into play. I'd like
> for example take advantage of IEEE floating point semantics in
> our Ada compiler. Fifteen years ago, we had to face the fact that

It's up to the Ada maintainers what is or is not considered floating-point 
behavior expected to be stable between versions, and so whether making Ada 
use -mfpmath=sse when SSE2 is available would be appropriate.

> So, I'd like to be able to put all this behind me, and only
> have to think about fully IEEE compliant systems. Similarly,
> there is no way to fully implement C99 Annex F without using
> SSE2.

I know some people have claimed (e.g. glibc bug 6981) that you can't 
conform to Annex F when you have excess precision, but this does not 
appear to be the view of WG14.

A proper implementation of Annex F is also likely to result in generating 
slower floating-point code if we keep the present default of 
-ftrapping-math being on by default (I think it would end up inhibiting 
optimizations as much as -frounding-math to ensure exactly the right set 
of exceptions is raised).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Change x86 default arch for 4.5?

[Vincent Lefevre]

On 2010-02-22 00:02:39 +0100, Erik Trulsson wrote:
> On the other hand code compiled for an older CPU that is run a newer
> CPU will run just fine, if slightly slower than they could have due to
> not making use of new instructions in the newer CPU.

It will run, but may give unexpected or even incorrect flaoting-point
results. See the number of duplicates (some of them can involve
double rounding) in:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Change x86 default arch for 4.5?

[Vincent Lefevre]

On 2010-02-22 01:57:48 +0000, Joseph S. Myers wrote:
> I know some people have claimed (e.g. glibc bug 6981) that you can't 
> conform to Annex F when you have excess precision, but this does not 
> appear to be the view of WG14.

I wonder what their view is. Annex F says:

  The +, −, *, and / operators provide the IEC 60559 add, subtract,
  multiply, and divide operations.

As IEC 60559 (= IEEE 754-1985) requires correct rounding to the
target format, double rounding is forbidden.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Change x86 default arch for 4.5?

[Geert Bosch]

On Feb 21, 2010, at 20:57, Joseph S. Myers wrote:
> I know some people have claimed (e.g. glibc bug 6981) that you can't 
> conform to Annex F when you have excess precision, but this does not 
> appear to be the view of WG14.

That may be the case, but I really wonder how much sense it
can make to declare things like:

> The expressions x − y and −(y − x) are not equivalent because 1 − 1 is +0 but −(1 − 1) is −0 (in the default rounding direction)

if you than have to wave hands and admit that either side might
be off by an arbitrary amount due to presence or absence of
double rounding, the whole statement becomes meaningless. 

In the end, what counts is thay users have complained for
ages about unexpected floating-point results on x86.
We have always argued that that was just the way things
are on x86: sorry, hardware issue, can't fix.

However, we have progressed 25 years, and through the wonders
of SSE2 we now can have both extended precision when we need
it and accurate, predictable single and double floating-point
for the rest. If we get this issue out of the way, and make
GCC by default have IEEE 754 compliant floating point on hardware
supporting it, that would be a great step forward.

  -Geert

Re: Change x86 default arch for 4.5?

[Joseph S. Myers]

On Mon, 22 Feb 2010, Vincent Lefevre wrote:

> On 2010-02-22 01:57:48 +0000, Joseph S. Myers wrote:
> > I know some people have claimed (e.g. glibc bug 6981) that you can't 
> > conform to Annex F when you have excess precision, but this does not 
> > appear to be the view of WG14.
> 
> I wonder what their view is. Annex F says:

For example, N1421 (Markham minutes) has a discussion that's clearly 
presuming that a conditional

#if defined(__STDC_IEC_559__) && (FLT_EVAL_METHOD == 1)

may hold.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Change x86 default arch for 4.5?

[Vincent Lefevre]

On 2010-02-22 02:58:19 +0000, Joseph S. Myers wrote:
> For example, N1421 (Markham minutes) has a discussion that's clearly 
> presuming that a conditional
> 
> #if defined(__STDC_IEC_559__) && (FLT_EVAL_METHOD == 1)
> 
> may hold.

Well, this is a bit unclear. I think this is OK, as long as rounding
of a float operation is done to single precision (the exponent range
may still be the one of the double format, in which case the value of
FLT_EVAL_METHOD should be 1 as above). IEEE 754-1985 says:

  4.3. Rounding Precision

  Normally, a result is rounded to the precision of its destination.
  However, some systems deliver results only to double or extended
  destinations. On such a system the user, which may be a high-level
  language compiler, shall be able to specify that a result be rounded
  instead to single precision, though it may be stored in the double
  or extended format with its wider exponent range. [...]

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Change x86 default arch for 4.5?

[Vincent Lefevre]

On 2010-02-22 05:23:39 +0100, Vincent Lefevre wrote:
> On 2010-02-22 02:58:19 +0000, Joseph S. Myers wrote:
> > For example, N1421 (Markham minutes) has a discussion that's clearly 
> > presuming that a conditional
> > 
> > #if defined(__STDC_IEC_559__) && (FLT_EVAL_METHOD == 1)
> > 
> > may hold.
> 
> Well, this is a bit unclear. I think this is OK, as long as rounding
> of a float operation is done to single precision (the exponent range
> may still be the one of the double format, in which case the value of
> FLT_EVAL_METHOD should be 1 as above). IEEE 754-1985 says:
[...]

Hmm... This doesn't seem to be allowed by the C language, though,
as C99 says for FLT_EVAL_METHOD == 1:

  evaluate operations and constants of type float and double to the
  range and precision of the double type,
        ^^^^^^^^^^^^^

So, this means that the precision of the double type should be single
precision in this case, but this is not allowed.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Change x86 default arch for 4.5?

[Andrew Haley]

On 02/21/2010 12:13 PM, Richard Guenther wrote:
> On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch <bosch@adacore.com> wrote:
>>
>> On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
>>> My point: gcc may fail to attract users (and/or may be losing users)
>>> when it tries to tailor to the needs of minorities.
>>>
>>> IMHO it would be much more reasonable to change the defaults to
>>> generate code that can run on, say, 95% of the computers still in use.
>>> If a user want to use the latest-and-greatest gcc for a really old
>>> machine, the burden of adding extra flags to change the default
>>> behavior of the compiler should be on that user.
>>>
>>> In this case of the i386 back end, that probably means changing the
>>> default to something like pentium3.
>>
>> The biggest change we need to make for x86 is to enable SSE2,
>> so we can get proper rounding behavior for float and double,
>> as well as significant performance increases.
> 
> I think Joseph fixed the rounding behavior for 4.5.  Also without an adjusted
> ABI you'd introduce x87 <-> SSE register moves which are not helpful
> for performance.

Exactly.  For example,

double plus(double a, double b)
{
  return a+b;
}

plus:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        movsd   16(%ebp), %xmm0
        addsd   8(%ebp), %xmm0
        movsd   %xmm0, -8(%ebp)
        fldl    -8(%ebp)
        leave
        ret

Andrew.

Re: Change x86 default arch for 4.5?

[Richard Guenther]

On Mon, Feb 22, 2010 at 11:27 AM, Andrew Haley <aph@redhat.com> wrote:
> On 02/21/2010 12:13 PM, Richard Guenther wrote:
>> On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch <bosch@adacore.com> wrote:
>>>
>>> On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
>>>> My point: gcc may fail to attract users (and/or may be losing users)
>>>> when it tries to tailor to the needs of minorities.
>>>>
>>>> IMHO it would be much more reasonable to change the defaults to
>>>> generate code that can run on, say, 95% of the computers still in use.
>>>> If a user want to use the latest-and-greatest gcc for a really old
>>>> machine, the burden of adding extra flags to change the default
>>>> behavior of the compiler should be on that user.
>>>>
>>>> In this case of the i386 back end, that probably means changing the
>>>> default to something like pentium3.
>>>
>>> The biggest change we need to make for x86 is to enable SSE2,
>>> so we can get proper rounding behavior for float and double,
>>> as well as significant performance increases.
>>
>> I think Joseph fixed the rounding behavior for 4.5.  Also without an adjusted
>> ABI you'd introduce x87 <-> SSE register moves which are not helpful
>> for performance.
>
> Exactly.  For example,
>
> double plus(double a, double b)
> {
>  return a+b;
> }
>
> plus:
>        pushl   %ebp
>        movl    %esp, %ebp
>        subl    $8, %esp
>        movsd   16(%ebp), %xmm0
>        addsd   8(%ebp), %xmm0
>        movsd   %xmm0, -8(%ebp)
>        fldl    -8(%ebp)
>        leave
>        ret

Yep.  As the issue only concerns return values we could start to
return in both %sp0 and %xmm0 for externally visible functions.
That would still have a spurios set of %sp0 and FP stack adjustment
but the caller could use %xmm0 and hope performance wouldn't
be affected too much.  Of course that's an ABI change that is
only compatible in one direction.

Richard.

Re: Change x86 default arch for 4.5?

[Andrew Haley]

On 02/22/2010 12:29 AM, Erik Trulsson wrote:
> On Sun, Feb 21, 2010 at 11:35:11PM +0000, Dave Korn wrote:
>> On 21/02/2010 22:42, Erik Trulsson wrote:
>>
>>> Yes, it does if the user is using binaries compiled by somebody else,
>>> and that somebody else did not explicitly specify any CPU-flags.
>>>
>>> I believe that is the situation when installing most
>>> Linux-distributions for example.
>>
>>   No, surely not.  The linux distributions use configure options
>> when they package their compilers to choose the default with-cpu
>> and with-arch options, and those are quite deliberately chosen
>> according to the binary standards of the distro.  It is hardly a
>> case of "somebody else did not explicitly specify" cpu flags; they
>> in fact explicitly specified them according to the system
>> requirements for the distro.  If your distro says it doesn't
>> support i386, this is *why*!
> 
> Are you sure of that?  Really sure?
> Some Linux distributions almost certainly do as you describe, but all
> of them?  I doubt it.

And I doubt otherwise.  Linux distros put a great deal of thought into
which machines they are targeting with their binary distributions.
And the existence of one tiny distro somewhere that doesn't would not
change that fact.

Andrew.

Re: Change x86 default arch for 4.5?

[Dave Korn]

On 22/02/2010 11:04, Andrew Haley wrote:
> On 02/22/2010 12:29 AM, Erik Trulsson wrote:
>> On Sun, Feb 21, 2010 at 11:35:11PM +0000, Dave Korn wrote:
>>> On 21/02/2010 22:42, Erik Trulsson wrote:
>>>
>>>> Yes, it does if the user is using binaries compiled by somebody else,
>>>> and that somebody else did not explicitly specify any CPU-flags.
>>>>
>>>> I believe that is the situation when installing most
>>>> Linux-distributions for example.
>>>   No, surely not.  The linux distributions use configure options
>>> when they package their compilers to choose the default with-cpu
>>> and with-arch options, and those are quite deliberately chosen
>>> according to the binary standards of the distro.  It is hardly a
>>> case of "somebody else did not explicitly specify" cpu flags; they
>>> in fact explicitly specified them according to the system
>>> requirements for the distro.  If your distro says it doesn't
>>> support i386, this is *why*!
>> Are you sure of that?  Really sure?
>> Some Linux distributions almost certainly do as you describe, but all
>> of them?  I doubt it.
> 
> And I doubt otherwise.  Linux distros put a great deal of thought into
> which machines they are targeting with their binary distributions.
> And the existence of one tiny distro somewhere that doesn't would not
> change that fact.

  Actually, there are probably dozens or hundreds of tiny distros out there
that are basically somebody's home-made repackaging-and-minor-variant of
existing bundles.  However, I think that these are the same distros that
constitute the 90% referred to in Sturgeon's Law, and so I would still not see
that as any reason to change GCC's defaults!

    cheers,
      DaveK

Re: Change x86 default arch for 4.5?

[Toon Moene]

Dave Korn wrote:

> On 21/02/2010 20:03, Martin Guy wrote:

>> The point about defaults is that the GCC default tends to filter down
>> into the default for distributions; 
> 
>   I'd find it surprising if that was really the way it happens; don't
> distributions make deliberate and conscious decisions about binary standards
> and things like that?  They certainly ought to be doing so, IMO, rather than
> just going with whatever-the-compiler-does-when-you-don't-tell-it-what-to-do.

This is Debian Testing as of last Sunday - note that it has had 
--with-arch-32=i486 for more time than I care to remember ...

hirlam@super:~$ gfortran -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-9' 
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --enable-multiarch --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9)

Hope this helps,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Re: Change x86 default arch for 4.5?

[Dave Korn]

On 22/02/2010 20:32, Toon Moene wrote:

[ Not singling you out here, yours just happens to be the latest reply: ]

> Dave Korn wrote:
> 
>> On 21/02/2010 20:03, Martin Guy wrote:
> 
>>> The point about defaults is that the GCC default tends to filter down
>>> into the default for distributions; 
>>
>>   I'd find it surprising if that was really the way it happens; don't
>> distributions make deliberate and conscious decisions about binary
>> standards and things like that?

> This is Debian Testing 

  Enough with the examples, already!  It was a rhetorical question!  :-)

    cheers,
      DaveK

Re: Change x86 default arch for 4.5?

[Piotr Wyderski]

H.J. Lu wrote:

> Default to SSE2 is a good first step.

I concur; all the programs I'm working on
require SSE2 and are not supposed to be
back-portable to SSE or fpu. Simply too
many vital optimizations require that ISA.

Best regards
Piotr Wyderski

Re: Change x86 default arch for 4.5?

[Jason Merrill]

On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
> On Thu, 18 Feb 2010, Jason Merrill wrote:
>
>> I periodically get bitten by bug 34115: a compiler configured without
>> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we would
>> only need to bump the default to i486 to get atomic support.  Can we
>> reconsider the default for 4.5?
>
> My position remains that configuring for i686-* should default to
> -march=i686 rather than -mtune=i686.
>
> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html
> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html
>
> Perhaps someone would like to review HJ's patch to that effect?
>
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html

Perhaps one of the i386 maintainers?

Jason

Re: Change x86 default arch for 4.5?

[Uros Bizjak]

On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill <jason@redhat.com> wrote:
> On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
>>
>> On Thu, 18 Feb 2010, Jason Merrill wrote:
>>
>>> I periodically get bitten by bug 34115: a compiler configured without
>>> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we
>>> would
>>> only need to bump the default to i486 to get atomic support.  Can we
>>> reconsider the default for 4.5?
>>
>> My position remains that configuring for i686-* should default to
>> -march=i686 rather than -mtune=i686.
>>
>> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html
>> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html
>>
>> Perhaps someone would like to review HJ's patch to that effect?
>>
>> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html
>
> Perhaps one of the i386 maintainers?

The default arch should be based on what _users_ expect from the
configure process, so it is IMO up to distributors and finally Release
Managers to decide.

As far as the proposed patch is concerned, I think that it is the step
in the right direction, and is OK for 4.6, but also please also add
-march=native choice. It works OK nowadays.

Since this is build patch, it also needs OK from build maintainer (CCd).

Uros.

Re: Change x86 default arch for 4.5?

[Paolo Bonzini]

On 02/25/2010 08:07 AM, Uros Bizjak wrote:
> On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill<jason@redhat.com>  wrote:
>> On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
>>>
>>> On Thu, 18 Feb 2010, Jason Merrill wrote:
>>>
>>>> I periodically get bitten by bug 34115: a compiler configured without
>>>> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we
>>>> would
>>>> only need to bump the default to i486 to get atomic support.  Can we
>>>> reconsider the default for 4.5?
>>>
>>> My position remains that configuring for i686-* should default to
>>> -march=i686 rather than -mtune=i686.
>>>
>>> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html
>>> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html
>>>
>>> Perhaps someone would like to review HJ's patch to that effect?
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html
>>
>> Perhaps one of the i386 maintainers?
>
> The default arch should be based on what _users_ expect from the
> configure process, so it is IMO up to distributors and finally Release
> Managers to decide.
>
> As far as the proposed patch is concerned, I think that it is the step
> in the right direction, and is OK for 4.6, but also please also add
> -march=native choice. It works OK nowadays.
>
> Since this is build patch, it also needs OK from build maintainer (CCd).

There are plenty of global reviewers in the CC list. :-)

Paolo

Re: Change x86 default arch for 4.5?

[Paolo Bonzini]

On 02/25/2010 08:07 AM, Uros Bizjak wrote:
> On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill<jason@redhat.com>  wrote:
>> On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
>>>
>>> On Thu, 18 Feb 2010, Jason Merrill wrote:
>>>
>>>> I periodically get bitten by bug 34115: a compiler configured without
>>>> --with-arch on i686-pc-linux-gnu doesn't support atomics.  I think we
>>>> would
>>>> only need to bump the default to i486 to get atomic support.  Can we
>>>> reconsider the default for 4.5?
>>>
>>> My position remains that configuring for i686-* should default to
>>> -march=i686 rather than -mtune=i686.
>>>
>>> http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html
>>> http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html
>>>
>>> Perhaps someone would like to review HJ's patch to that effect?
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html
>>
>> Perhaps one of the i386 maintainers?
>
> The default arch should be based on what _users_ expect from the
> configure process, so it is IMO up to distributors and finally Release
> Managers to decide.
>
> As far as the proposed patch is concerned, I think that it is the step
> in the right direction, and is OK for 4.6, but also please also add
> -march=native choice. It works OK nowadays.
>
> Since this is build patch, it also needs OK from build maintainer (CCd).

There are plenty of global reviewers in the CC list. :-)

Paolo

Re: Change x86 default arch for 4.5?

[Jason Merrill]

On 02/25/2010 05:37 AM, Paolo Bonzini wrote:
>> Since this is build patch, it also needs OK from build maintainer (CCd).
>
> There are plenty of global reviewers in the CC list. :-)

Yep, I've just been trying to get people who might know why the status 
quo is the way it is to weigh in before I approve it.

H.J., could you update your patch to support --with-arch/cpu=native as 
Uros requested?

Jason

Re: Change x86 default arch for 4.5?

[H.J. Lu]

On Thu, Feb 25, 2010 at 2:01 PM, Jason Merrill <jason@redhat.com> wrote:
> On 02/25/2010 05:37 AM, Paolo Bonzini wrote:
>>>
>>> Since this is build patch, it also needs OK from build maintainer (CCd).
>>
>> There are plenty of global reviewers in the CC list. :-)
>
> Yep, I've just been trying to get people who might know why the status quo
> is the way it is to weigh in before I approve it.
>
> H.J., could you update your patch to support --with-arch/cpu=native as Uros
> requested?
>

Here it is:

http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01095.html


-- 
H.J.

Re: Change x86 default arch for 4.5?

[Gerald Pfeifer]

On Mon, 22 Feb 2010, Erik Trulsson wrote:
> As for the relative hurts.  Code compiled for a newer CPU (making use
> of newer instructions) will not run at all on older CPUs not supporting
> those newer instructions.  Much hurt there.
> 
> On the other hand code compiled for an older CPU that is run a newer
> CPU will run just fine, if slightly slower than they could have due
> to not making use of new instructions in the newer CPU.

That can well be seen as a point for _making_ the change:  when it
fails, the user/admin knows there is a need to adjust, whereas silent
degradation will continue to make look GCC bad and hurt its traction
and adoption (as Steven and others have experienced).

Gerald