Target CPU default selection on alpha

Target CPU default selection on alpha

[Rainer Orth]

Currently gcc/configure.in sets TARGET_CPU_DEFAULT for alpha* targets based
on the cpu type of the machine used to configure and build gcc, as
determined by config.guess (alpha, alphaev5, alphaev56, alphapca56,
alphaev6).  While this is convenient for a single machine, I suppose it may
cause problems when the resulting gcc is run on a machine with a different
cpu type: e.g. configured for a 21164/ev5, but run on a 21064/ev4.

I'm not sure if this really causes problems on various alpha cpus
(cf. SPARC: using hardware multiplication on SPARC V7 machines causes
kernel emulation of the relevant instructions), but its more in line with
the treatment of other processors to leave this choice to the user (via
--with-cpu=).

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Technical Faculty, University of Bielefeld

Internet: ro@TechFak.Uni-Bielefeld.DE

Re: Target CPU default selection on alpha

[Jeffrey A Law]

  In message < 13946.51325.27183.182995@xayide.TechFak.Uni-Bielefeld.DE >you writ
e:
  > Currently gcc/configure.in sets TARGET_CPU_DEFAULT for alpha* targets based
  > on the cpu type of the machine used to configure and build gcc, as
  > determined by config.guess (alpha, alphaev5, alphaev56, alphapca56,
  > alphaev6).  While this is convenient for a single machine, I suppose it may
  > cause problems when the resulting gcc is run on a machine with a different
  > cpu type: e.g. configured for a 21164/ev5, but run on a 21064/ev4.
  > 
  > I'm not sure if this really causes problems on various alpha cpus
  > (cf. SPARC: using hardware multiplication on SPARC V7 machines causes
  > kernel emulation of the relevant instructions), but its more in line with
  > the treatment of other processors to leave this choice to the user (via
  > --with-cpu=).
There's two choices.

1. Generate appropriate code for whatever system you're building on.

2. Generate code for the least common denominator.


Sounds like gcc defaults to #1 for Sparcs, which is fine.  If you want to
generate "common" mode binaries, then you need to configure for the target
which is the least common denominator for your systems.

jeff

Re: Target CPU default selection on alpha

[Richard Henderson]

On Fri, Dec 18, 1998 at 10:26:21PM +0100, Rainer Orth wrote:
> While this is convenient for a single machine, I suppose it may
> cause problems when the resulting gcc is run on a machine with a different
> cpu type: e.g. configured for a 21164/ev5, but run on a 21064/ev4.

Not that particular example, but for example ev56 won't run on ev5.

> but its more in line with the treatment of other processors to leave
> this choice to the user (via --with-cpu=).

Hum..  I hadn't really given it much thought, since the alpha
port has "always" done it that way.  I suppose it would be 
better, since there would be less in the way of user error.


r~

Re: Target CPU default selection on alpha

[Jeffrey A Law]

  In message < 19981218203058.A23463@dot.cygnus.com >you write:
  > On Fri, Dec 18, 1998 at 10:26:21PM +0100, Rainer Orth wrote:
  > > While this is convenient for a single machine, I suppose it may
  > > cause problems when the resulting gcc is run on a machine with a differen
  > t
  > > cpu type: e.g. configured for a 21164/ev5, but run on a 21064/ev4.
  > 
  > Not that particular example, but for example ev56 won't run on ev5.
  > 
  > > but its more in line with the treatment of other processors to leave
  > > this choice to the user (via --with-cpu=).
  > 
  > Hum..  I hadn't really given it much thought, since the alpha
  > port has "always" done it that way.  I suppose it would be 
  > better, since there would be less in the way of user error.
The PA (and other) ports have always done it like the alpha too.

There isn't any kind of consistency in this area.  For example the ppc
defaults to "common" mode.

It's not 100% clear that either choice is right.  There's arguments for
and against defaulting to the least common denominator for code generation.

Jeff

Re: Target CPU default selection on alpha

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> In message < 19981218203058.A23463@dot.cygnus.com >you write:
>> On Fri, Dec 18, 1998 at 10:26:21PM +0100, Rainer Orth wrote:
>> > While this is convenient for a single machine, I suppose it may
>> > cause problems when the resulting gcc is run on a machine with a differen
>> t
>> > cpu type: e.g. configured for a 21164/ev5, but run on a 21064/ev4.
>> 
>> Not that particular example, but for example ev56 won't run on ev5.
>> 
>> > but its more in line with the treatment of other processors to leave
>> > this choice to the user (via --with-cpu=).
>> 
>> Hum..  I hadn't really given it much thought, since the alpha
>> port has "always" done it that way.  I suppose it would be 
>> better, since there would be less in the way of user error.

Jeff> There isn't any kind of consistency in this area.  For example the ppc
Jeff> defaults to "common" mode.

Jeff> It's not 100% clear that either choice is right.  There's arguments for
Jeff> and against defaulting to the least common denominator for code generation.

	All operating systems other than AIX default to a particular
architecture.  IBM's XLC compiler for AIX defaults to "common" mode and a
substantial number of users were getting confused when GCC did not behave
the same way.  Also, the POWER and PowerPC architectures are fixed and not
changing with each processor revision.  And neither POWER nor PowerPC are
a true subset of the other architecture.  It did not make sense for the
architecture to be decided arbitrarily based on the particular system on
which GCC was built in a multi-architecture site.

David

Re: Target CPU default selection on alpha

[Jeffrey A Law]

  In message < 9812211631.AA30948@marc.watson.ibm.com >you write:
  > 	All operating systems other than AIX default to a particular
  > architecture.  IBM's XLC compiler for AIX defaults to "common" mode and a
  > substantial number of users were getting confused when GCC did not behave
  > the same way.  Also, the POWER and PowerPC architectures are fixed and not
  > changing with each processor revision.  And neither POWER nor PowerPC are
  > a true subset of the other architecture.  It did not make sense for the
  > architecture to be decided arbitrarily based on the particular system on
  > which GCC was built in a multi-architecture site.
Yea, I remember numerous problems when we did not generate common code on the
rs6000/ppc port in the past.  I believe the decision made for the rs6000/ppc
port was the right decision.

What I meant was that it's not clear that generating common code may not be
the best thing to do for each port.

jeff

Re: Target CPU default selection on alpha

[Rainer Orth]

> The PA (and other) ports have always done it like the alpha too.

From a quick check of current CVS configure.in, the c*-convex-*, several
hppa1.1-*-* and hppa2*-*-*, the i[4-7]86-*-* and alpha*-*-* targets behave
this way.  All others default to the least common denominator.

> There isn't any kind of consistency in this area.  For example the ppc
> defaults to "common" mode.

Than perhaps now it's time to become consistent, or at least document why
some targets have a different default.

> It's not 100% clear that either choice is right.  There's arguments for
> and against defaulting to the least common denominator for code generation.

What are the primary arguments against defaulting to least common
denominator, beyond performance?

I think the decision should be left to the user.  Or at least the user
should be aware of the choice and it's consequences.

	Rainer

Re: Target CPU default selection on alpha

[Jeffrey A Law]

  > >From a quick check of current CVS configure.in, the c*-convex-*, several
  > hppa1.1-*-* and hppa2*-*-*, the i[4-7]86-*-* and alpha*-*-* targets behave
  > this way.  All others default to the least common denominator.
  > 
  > > There isn't any kind of consistency in this area.  For example the ppc
  > > defaults to "common" mode.
  > 
  > Than perhaps now it's time to become consistent, or at least document why
  > some targets have a different default.
I don't think we need to be consistent in this area.  Doing so can greatly
impact performance on some machines.


  > What are the primary arguments against defaulting to least common
  > denominator, beyond performance?
Performance.

  > I think the decision should be left to the user.  Or at least the user
  > should be aware of the choice and it's consequences.
The user still has the ability to configure for a common toolchain by using
the least common denominator configure string.  Most (all) ports also have
options which allow for generation of code for a particular processor.  So
for the PA one could configure with:

configure hppa1.0-hp-hpux10.20

Which would build a compiler which defaulted to hppa1.0 code generation, which
is the least common denominator for the PA architecture.

Or, given any PA compiler, the user can force code generation for a particular
chip with -mpa-risc-X-Y where X-Y represents different variants within the
PA family (1-0, 1-1, 2-0, and so on in the future).

jeff