S/390: -march= and -mcpu= options

S/390: -march= and -mcpu= options

[Hartmut Penner]

Hello,
        this patch introduce the -march= and -mcpu= options. Right now, 
only three systems are distinguished, g5, g6 and z900.

        Bootstrapped/regtested on s390-ibm-linux-gnu and s390x-ibm-linux-gnu.

ChangeLog:
        	* doc/invoke.texi: Document -mzarch, -mesa, -mcpu= and -march=
		option for S/390 and zSeries.
                * config/s390/s390.c (s390_cpu, s390_cpu_string, s390_arch,
                s390_arch_string): New variables.
                (override_options): Checking for options and setting of 
		appropriate target_flags, cpu and arch flags.
                * config/s390/s390.h: (processor_type): New enum.
                (TARGET_SWITCHES): New switches -mesa/zarch.
                * config/s390/s390.md: New attribute 'cpu'.

Index: doc/invoke.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.213
diff -c -p -r1.213 invoke.texi
*** doc/invoke.texi	19 Dec 2002 20:34:43 -0000	1.213
--- doc/invoke.texi	20 Dec 2002 12:50:39 -0000
*************** in the following sections.
*** 656,664 ****
  
  @emph{S/390 and zSeries Options}
  @gccoptlist{
  -mhard-float  -msoft-float  -mbackchain  -mno-backchain @gol
  -msmall-exec  -mno-small-exec  -mmvcle -mno-mvcle @gol
! -m64 -m31 -mdebug -mno-debug}
  
  @emph{CRIS Options}
  @gccoptlist{
--- 656,665 ----
  
  @emph{S/390 and zSeries Options}
  @gccoptlist{
+ -mcpu=@var{cpu-type} -march=@var{cpu-type} @gol
  -mhard-float  -msoft-float  -mbackchain  -mno-backchain @gol
  -msmall-exec  -mno-small-exec  -mmvcle -mno-mvcle @gol
! -m64 -m31 -mdebug -mno-debug -mesa -mzarch}
  
  @emph{CRIS Options}
  @gccoptlist{
*************** particular to generate 64-bit instructio
*** 9803,9808 ****
--- 9804,9821 ----
  targets, the default is @option{-m31}, while the @samp{s390x}
  targets default to @option{-m64}.
  
+ @item -mzarch
+ @itemx -mesa
+ @opindex mzarch
+ @opindex mesa
+ When @option{-mzarch} is specified, generate code using the 
+ instructions available on z/Architecture. 
+ When @option{-mesa} is specified, generate code using the 
+ instructions available on ESA/390. Note that @option{-mesa} is
+ not possible with @option{-m64}.
+ For the @samp{s390} targets, the default is @option{-mesa}, 
+ while the @samp{s390x} targets default to @option{-mzarch}.
+ 
  @item -mmvcle
  @itemx -mno-mvcle
  @opindex mmvcle
*************** use a @code{mvc} loop instead.  This is 
*** 9817,9822 ****
--- 9830,9847 ----
  @opindex mno-debug
  Print (or do not print) additional debug information when compiling.
  The default is to not print debug information.
+ 
+ @item -march=@var{arch}
+ @opindex march
+ Generate code that will run on @var{arch}, which is the name of system
+ representing a certain processor type. Possible values for
+ @var{cpu-type} are @samp{g5}, @samp{g6} and @samp{z900}. 
+ 
+ @item -mcpu=@var{arch}
+ @opindex mcpu
+ Tune to @var{cpu-type} everything applicable about the generated code,
+  except for the ABI and the set of available instructions. 
+ The list of @var{arch} values is the same as for @option{-march}.
  
  @end table
  
Index: config/s390/s390.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.c,v
retrieving revision 1.72
diff -c -p -r1.72 s390.c
*** config/s390/s390.c	17 Dec 2002 12:38:58 -0000	1.72
--- config/s390/s390.c	20 Dec 2002 12:50:48 -0000
*************** struct s390_address
*** 117,122 ****
--- 117,131 ----
    int pointer;
  };
  
+ /* Which cpu are we scheduling for.  */
+ enum processor_type s390_cpu;
+ /* Which instruction set architecture to use.  */
+ enum processor_type s390_arch;
+ 
+ /* Strings to hold which cpu and instruction set architecture  to use.  */
+ const char *s390_cpu_string;		/* for -mcpu=<xxx> */
+ const char *s390_arch_string;		/* for -march=<xxx> */
+ 
  /* Define the structure for the machine field in struct function.  */
  
  struct machine_function GTY(())
*************** optimization_options (level, size)
*** 832,842 ****
--- 841,925 ----
  void
  override_options ()
  {
+   int i;
+   static const char * const cpu_names[] = TARGET_CPU_DEFAULT_NAMES;
+   static struct pta
+     {
+       const char *const name;		/* processor name or nickname.  */
+       const enum processor_type processor;
+       const enum pta_flags
+ 	{
+ 	  PTA_IEEE_FLOAT = 1,
+ 	  PTA_ZARCH = 2
+ 	} flags;
+     }
+   const processor_alias_table[] =
+     {
+       {"g5", PROCESSOR_9672_G5, PTA_IEEE_FLOAT},
+       {"g6", PROCESSOR_9672_G6, PTA_IEEE_FLOAT},
+       {"z900", PROCESSOR_2064_Z900, PTA_IEEE_FLOAT | PTA_ZARCH},
+     };
+ 
+   int const pta_size = ARRAY_SIZE (processor_alias_table);
+ 
    /* Acquire a unique set number for our register saves and restores.  */
    s390_sr_alias_set = new_alias_set ();
  
    /* Set up function hooks.  */
    init_machine_status = s390_init_machine_status;
+  
+   /* Set cpu and arch, if only partially given.  */
+   if (!s390_cpu_string && s390_arch_string)
+     s390_cpu_string = s390_arch_string;
+   if (!s390_cpu_string)
+     s390_cpu_string = cpu_names [TARGET_64BIT ? TARGET_CPU_DEFAULT_2064
+                                               :	TARGET_CPU_DEFAULT_9672];
+   if (!s390_arch_string)
+ #ifdef DEFAULT_TARGET_64BIT
+     s390_arch_string = "z900";
+ #else
+     s390_arch_string = "g5";
+ #endif
+ 
+   for (i = 0; i < pta_size; i++)
+     if (! strcmp (s390_arch_string, processor_alias_table[i].name))
+       {
+ 	s390_arch = processor_alias_table[i].processor;
+ 	/* Default cpu tuning to the architecture.  */
+ 	s390_cpu = s390_arch;
+      
+ 	if (!(processor_alias_table[i].flags & PTA_ZARCH) 
+             && TARGET_64BIT)
+           error ("64-bit ABI not supported on %s", s390_arch_string);
+ 
+ 	if (!(processor_alias_table[i].flags & PTA_ZARCH) 
+             && TARGET_ZARCH)
+           error ("z/Architecture not supported on %s", s390_arch_string);
+ 
+ 	break;
+       }
+ 
+   if (i == pta_size)
+     error ("bad value (%s) for -march= switch", s390_arch_string);
+ 
+   /* ESA implies 31 bit mode.  */
+   if ((target_flags_explicit & MASK_ZARCH) && !TARGET_ZARCH)
+     {
+       if ((target_flags_explicit & MASK_64BIT) && TARGET_64BIT)
+ 	error ("64-bit ABI not possible in ESA/390 mode");
+       else
+ 	target_flags &= ~MASK_64BIT;
+     }
+ 
+   for (i = 0; i < pta_size; i++)
+     if (! strcmp (s390_cpu_string, processor_alias_table[i].name))
+       {
+ 	s390_cpu = processor_alias_table[i].processor;
+ 	break;
+       }
+ 
+   if (i == pta_size)
+     error ("bad value (%s) for -mcpu= switch", s390_cpu_string);
  }
  
  /* Map for smallest class containing reg regno.  */
Index: config/s390/s390.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.h,v
retrieving revision 1.54
diff -c -p -r1.54 s390.h
*** config/s390/s390.h	16 Dec 2002 18:21:52 -0000	1.54
--- config/s390/s390.h	20 Dec 2002 12:50:49 -0000
*************** Boston, MA 02111-1307, USA.  */
*** 28,33 ****
--- 28,55 ----
  #include <s390/fixdfdi.h>
  #endif
  
+ /* Which processor to generate code or schedule for. The cpu attribute 
+    defines a list that mirrors this list, so changes to s390.md must be
+    made at the same time.  */
+ 
+ enum processor_type
+ {
+   PROCESSOR_9672_G5,		
+   PROCESSOR_9672_G6,		
+   PROCESSOR_2064_Z900,		
+   PROCESSOR_max
+ };
+ 
+ extern enum processor_type s390_cpu;
+ extern const char *s390_cpu_string;
+ 
+ extern enum processor_type s390_arch;
+ extern const char *s390_arch_string;
+ 
+ #define TARGET_CPU_DEFAULT_9672 0
+ #define TARGET_CPU_DEFAULT_2064 2
+ 
+ #define TARGET_CPU_DEFAULT_NAMES {"g5", "g6", "z900"}
  
  /* Run-time target specification.  */
  
*************** Boston, MA 02111-1307, USA.  */
*** 46,83 ****
  /* Optional target features.  */
  extern int target_flags;
  
! #define TARGET_HARD_FLOAT          (target_flags & 1)
! #define TARGET_SOFT_FLOAT          (!(target_flags & 1))
! #define TARGET_BACKCHAIN           (target_flags & 2)
! #define TARGET_SMALL_EXEC          (target_flags & 4)
! #define TARGET_DEBUG_ARG           (target_flags & 8)
! #define TARGET_64BIT               (target_flags & 16)
! #define TARGET_MVCLE               (target_flags & 32)
  
  /* ??? Once this actually works, it could be made a runtime option.  */
  #define TARGET_IBM_FLOAT           0
  #define TARGET_IEEE_FLOAT          1
  
  #ifdef DEFAULT_TARGET_64BIT
! #define TARGET_DEFAULT             0x13
  #else
  #define TARGET_DEFAULT             0x3
  #endif
  
! #define TARGET_SWITCHES           		       		       \
! { { "hard-float",    1, N_("Use hardware fp")},         		       \
!   { "soft-float",   -1, N_("Don't use hardware fp")},	      	       \
!   { "backchain",     2, N_("Set backchain")},           		       \
    { "no-backchain", -2, N_("Don't set backchain (faster, but debug 
harder")}, \
!   { "small-exec",    4, N_("Use bras for execucable < 64k")},           \
!   { "no-small-exec",-4, N_("Don't use bras")},            	       \
!   { "debug",         8, N_("Additional debug prints")},        	       \
!   { "no-debug",     -8, N_("Don't print additional debug prints")},     \
!   { "64",           16, N_("64 bit mode")},         	               \
!   { "31",          -16, N_("31 bit mode")},                             \
!   { "mvcle",        32, N_("mvcle use")},         	               \
!   { "no-mvcle",    -32, N_("mvc&ex")},                                  \
    { "", TARGET_DEFAULT, 0 } }
  
  /* Target version string.  Overridden by the OS header.  */
  #ifdef DEFAULT_TARGET_64BIT
--- 68,123 ----
  /* Optional target features.  */
  extern int target_flags;
  
! #define MASK_HARD_FLOAT            0x01
! #define MASK_BACKCHAIN             0x02
! #define MASK_SMALL_EXEC            0x04
! #define MASK_DEBUG_ARG             0x08
! #define MASK_64BIT                 0x10
! #define MASK_ZARCH                 0x20
! #define MASK_MVCLE                 0x40
! 
! #define TARGET_HARD_FLOAT          (target_flags & MASK_HARD_FLOAT)
! #define TARGET_SOFT_FLOAT          (!(target_flags & MASK_HARD_FLOAT))
! #define TARGET_BACKCHAIN           (target_flags & MASK_BACKCHAIN)
! #define TARGET_SMALL_EXEC          (target_flags & MASK_SMALL_EXEC)
! #define TARGET_DEBUG_ARG           (target_flags & MASK_DEBUG_ARG)
! #define TARGET_64BIT               (target_flags & MASK_64BIT)
! #define TARGET_ZARCH               (target_flags & MASK_ZARCH)
! #define TARGET_MVCLE               (target_flags & MASK_MVCLE)
  
  /* ??? Once this actually works, it could be made a runtime option.  */
  #define TARGET_IBM_FLOAT           0
  #define TARGET_IEEE_FLOAT          1
  
  #ifdef DEFAULT_TARGET_64BIT
! #define TARGET_DEFAULT             0x33
  #else
  #define TARGET_DEFAULT             0x3
  #endif
  
! #define TARGET_SWITCHES                                                \
! { { "hard-float",    1, N_("Use hardware fp")},                        \
!   { "soft-float",   -1, N_("Don't use hardware fp")},                  \
!   { "backchain",     2, N_("Set backchain")},                          \
    { "no-backchain", -2, N_("Don't set backchain (faster, but debug 
harder")}, \
!   { "small-exec",    4, N_("Use bras for execucable < 64k")},          \
!   { "no-small-exec",-4, N_("Don't use bras")},                         \
!   { "debug",         8, N_("Additional debug prints")},                \
!   { "no-debug",     -8, N_("Don't print additional debug prints")},    \
!   { "64",           16, N_("64 bit ABI")},                             \
!   { "31",          -16, N_("31 bit ABI")},                             \
!   { "zarch",        32, N_("z/Architecture")},                         \
!   { "esa",         -32, N_("ESA/390 architecture")},                   \
!   { "mvcle",        64, N_("mvcle use")},                              \
!   { "no-mvcle",    -64, N_("mvc&ex")},                                 \
    { "", TARGET_DEFAULT, 0 } }
+ 
+ #define TARGET_OPTIONS                                          \
+ { { "cpu=",             &s390_cpu_string,                       \
+     N_("Schedule code for given CPU")},                         \
+   { "arch=",            &s390_arch_string,                      \
+     N_("Generate code for given CPU")},                         \
+ }
  
  /* Target version string.  Overridden by the OS header.  */
  #ifdef DEFAULT_TARGET_64BIT
Index: config/s390/s390.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.md,v
retrieving revision 1.43
diff -c -p -r1.43 s390.md
*** config/s390/s390.md	19 Dec 2002 19:55:12 -0000	1.43
--- config/s390/s390.md	20 Dec 2002 12:50:59 -0000
***************
*** 44,49 ****
--- 44,54 ----
  ;;   s_operand -- Matches a valid S operand in a RS, SI or SS type 
instruction.
  ;;
  
+ ;; Processor type.  This attribute must exactly match the processor_type
+ ;; enumeration in s390.h.
+ 
+ (define_attr "cpu" "g5,g6,z900"
+   (const (symbol_ref "s390_cpu")))
  
  ;; Define an insn type attribute.  This is used in function unit delay
  ;; computations.

Re: S/390: -march= and -mcpu= options

[R. Kelley Cook]

  >Hello,
  > this patch introduce the -march= and -mcpu= options.
  > Right now, only three systems are distinguished, g5, g6 and z900.

I would suggest, like some ports already have, using the much more 
intuitive "-mtune" instead of "-mcpu".  I was going to submit a patch
to add the "-mtune" synonym to the x86 port.

Kelley Cook

Re: S/390: -march= and -mcpu= options

[Ulrich Weigand]

Richard Earnshaw wrote:

> The problem here is that tuning for an architecture (ie an abstract ISA) 
> can be meaningless.  There can be multiple implementations of an ISA with 
> different trade-offs.  You just can't guess and give good results.

I think the question here is really in what terms the 'architecture'
is specified (I guess this is also what David Edelsohn was talking
about earlier on).  If the set of tags after -march= is different
from the set of tags after -mtune=, then this becomes a issue.

However, I was imagining that after -march=, you simply specific an
*CPU* name; the implication being 'assume the ISA as implemented by
the CPU xxx'.  

At least on S/390, I cannot think of any practical means of specifying 
an ISA; the official description of the ISA on a S/390 G6 CPU, for example, 
would be:  Enterprise Systems Architecture/390 with the following 
optional architecture features installed: string-instruction facility, 
immediate-and-relative-instruction facility, compare-and-move-extended 
facility, checksum facility, floating-point extension facilities.  (This
includes only those facilities that GCC currently makes use of, the full 
list would be quite a bit longer.)

IMO it would be impractical to require the user to specify the
architecture on this level; what the user wants to say is 'use 
whatever architecture facilities a G6 provides' ...


Now, *if* the user specifies a CPU name as argument to -march=,
and does not specify any -mtune= switch, I would consider it
reasonable to default -mtune= to that CPU that was given with
-march=.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: S/390: -march= and -mcpu= options

[Richard Earnshaw]

> On Dec 23, 2002, Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de> wrote:
> 
> >> Second, the people who participated in the earlier discussion
> >> agreed that there should be a shorthand.
> 
> > Why shouldn't -march=z900 be enough?
> 
> It should.  IMHO, any sane implementation of -march/-mtune should tune
> for the specified arch unless an -mtune argument is present, which
> renders -mcpu (which is an alias for -march -mtune) totally useless.
> 
> The only exception I can think of is in case the default tuning is
> something actually more recent than the default arch, in which case
> someone might want to downgrade the arch without downgrading tuning.
> This probably happens seldom enough, if ever, that arranging for
> -march to be the -mtune default is perfectly reasonable.
> 

The problem here is that tuning for an architecture (ie an abstract ISA) 
can be meaningless.  There can be multiple implementations of an ISA with 
different trade-offs.  You just can't guess and give good results.

R.

Re: S/390: -march= and -mcpu= options

[David Edelsohn]

>>>>> Hartmut Penner writes:

Hartmut> But with that I don't see any reason for the mcpu-option.
Hartmut> If I want to compile my program for a recent architecture, I'm
Hartmut> using the march option only,
Hartmut> with the algorithm above, the tune will be at least for this architecture.
Hartmut> The only advantage the mcpu option has is to potentially lower
Hartmut> the tune to the same level as the architecture.
Hartmut> But for this I can't see anybody, except us backend maintainer,
Hartmut> who may need this. But this can be done with the explicit tune option.

	An option specifying processor features and scheduling needs to
accept processor names.  With the other work throughout GCC correcting
spelling and terminology, designing march ("architecture") to accept a
processor name seems like a step backward except under the "deprecate and
be lenient in what you accept" rule.

David

Re: S/390: -march= and -mcpu= options

[Hartmut Penner]

>Here I don't agree.
>For example, consider x86.
>The default arch should be 386, to ensure wide compatibility.
>The default tuning should be for something a lot more modern,
>e.g. Pentium-<mumble>.
>If an application is compiled with the arch set to 486 (-march=486),
>this should not alter the default tuning.
,
Yes, the tune should be the maximum from default tune and arch, if not
explicit set.

But with that I don't see any reason for the mcpu-option.
If I want to compile my program for a recent architecture, I'm using the
march option only,
with the algorithm above, the tune will be at least for this architecture.
The only advantage
the mcpu option has is to potentially lower the tune to the same level as
the architecture.
But for this I can't see anybody, except us backend maintainer, who may
need this. But
this can be done with the explicit tune option.

Hartmut Penner

Re: S/390: -march= and -mcpu= options

[Fergus Henderson]

On 24-Dec-2002, Alexandre Oliva <aoliva@redhat.com> wrote:
> IMHO, any sane implementation of -march/-mtune should tune
> for the specified arch unless an -mtune argument is present, which
> renders -mcpu (which is an alias for -march -mtune) totally useless.
> 
> The only exception I can think of is in case the default tuning is
> something actually more recent than the default arch, in which case
> someone might want to downgrade the arch without downgrading tuning.

Or they might want to upgrade the arch, but still to a point which
is lower than the default tuning.

> This probably happens seldom enough, if ever, that arranging for
> -march to be the -mtune default is perfectly reasonable.

For any long-lived architecture, it is likely that the default arch
will not match the default tuning.

Anyway, fewer options doesn't necessarily make it easier for users
to understand and use.  I think it would be much cleaner to have
-march setting the arch (only), -mtune setting the tuning (only),
and another option for setting both at once.  If there are historical
problems with using `-mcpu' for that, another name could be chosen,
e.g. `-mtarget'.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: S/390: -march= and -mcpu= options

[Fergus Henderson]

On 24-Dec-2002, Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de> wrote:
> David Edelsohn wrote:
> 
> > 	Your premise is wrong.  z900 64-bit code cannot run on a G5
> > system, but G5 code can run on a z900 system.  One may want to compile
> > applications tuned for systems with the widest deployment or tuned for
> > newest systems.
> 
> Sure, I agree that we need something like a -mtune option, however it
> is called, that allows to generate code tuned for a new CPU but still
> running on old CPUs.  However, *if* the user employs the -march option
> to allow generation of code that does *not* run on old CPUs, it would
> be strange to tune such code to an old CPU which it cannot run on,
> wouldn't it?  

Yes.

Perhaps GCC should issue a warning message in this case.

> Thus, if there is no explicit -mtune option, it should IMO always
> default to the CPU type specified with -march.

Here I don't agree.
For example, consider x86.
The default arch should be 386, to ensure wide compatibility.
The default tuning should be for something a lot more modern,
e.g. Pentium-<mumble>.
If an application is compiled with the arch set to 486 (-march=486),
this should not alter the default tuning.

The only time it makes sense to override the default tuning is when
the default tuning is for a system which does not support the specified
arch.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: S/390: -march= and -mcpu= options

[Eric Christopher]

> 	Interesting that whenever I speak to Red Hat people privately,
> they say the Mips port is a mess and evolved badly, requiring the current
> re-write. 
> 

Yes, and I'd agree with that here as well.

> 	The "SC" never agreed to standardize on "arch" and "tune".  Your
> survey sample of "maintainers" may have been too small.
> 

I surveyed on here and with most of the major port maintainers. You'll
also note that the change to use these options is relatively recent as
well - beginning with the rewrites that have been going on.

-eric

-- 
Yeah, I used to play basketball...

Re: S/390: -march= and -mcpu= options

[Alexandre Oliva]

On Dec 23, 2002, Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de> wrote:

>> Second, the people who participated in the earlier discussion
>> agreed that there should be a shorthand.

> Why shouldn't -march=z900 be enough?

It should.  IMHO, any sane implementation of -march/-mtune should tune
for the specified arch unless an -mtune argument is present, which
renders -mcpu (which is an alias for -march -mtune) totally useless.

The only exception I can think of is in case the default tuning is
something actually more recent than the default arch, in which case
someone might want to downgrade the arch without downgrading tuning.
This probably happens seldom enough, if ever, that arranging for
-march to be the -mtune default is perfectly reasonable.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: S/390: -march= and -mcpu= options

[Daniel Jacobowitz]

On Tue, Dec 24, 2002 at 12:00:51PM -0500, David Edelsohn wrote:
> >>>>> Eric Christopher writes:
> 
> > 	I would not consider the current Mips port in the FSF sources to
> > be a good precedent for GCC ports.
> 
> Eric> I would. In fact, I chose arch and tune at the suggestion of the other
> Eric> maintainers and the SC as the correct usage for ports "going forward".
> 
> 	Interesting that whenever I speak to Red Hat people privately,
> they say the Mips port is a mess and evolved badly, requiring the current
> re-write. 

You'll note that the change to use -march and -mtune the way they are
now is (relatively speaking) recent.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: S/390: -march= and -mcpu= options

[David Edelsohn]

>>>>> Eric Christopher writes:

> 	I would not consider the current Mips port in the FSF sources to
> be a good precedent for GCC ports.

Eric> I would. In fact, I chose arch and tune at the suggestion of the other
Eric> maintainers and the SC as the correct usage for ports "going forward".

	Interesting that whenever I speak to Red Hat people privately,
they say the Mips port is a mess and evolved badly, requiring the current
re-write. 

	The "SC" never agreed to standardize on "arch" and "tune".  Your
survey sample of "maintainers" may have been too small.

David

Re: S/390: -march= and -mcpu= options

[Ulrich Weigand]

David Edelsohn wrote:

> 	Compatibility with pre-G5 processors.  I am not referring to
> command-line compatibility.

But what does this have to do with the question whether -mcpu
is required and/or useful in addition to -march and -mtune?

> 	Your premise is wrong.  z900 64-bit code cannot run on a G5
> system, but G5 code can run on a z900 system.  One may want to compile
> applications tuned for systems with the widest deployment or tuned for
> newest systems.  Commercial compilers from hardware vendors like HP, IBM,
> SGI, Sun, etc. frequently do the latter -- one wants applications to run
> best on new hardware while remaining backward compatible with the earliest
> architecture still supported.

Sure, I agree that we need something like a -mtune option, however it
is called, that allows to generate code tuned for a new CPU but still
running on old CPUs.  However, *if* the user employs the -march option
to allow generation of code that does *not* run on old CPUs, it would
be strange to tune such code to an old CPU which it cannot run on,
wouldn't it?  

Thus, if there is no explicit -mtune option, it should IMO always
default to the CPU type specified with -march.  If so, the -mcpu 
you have suggested becomes synonymous to -march, however.

> 	It would be useful to have consistent options in all GCC ports.
> -march=, -mtune=, and -mcpu= have individual merit and well-defined
> meaning.  It would be helpful if the s390 port adopted the same
> conventions as other ports, especially because it is not difficult to
> implement the semantics of the three options.

I certainly agree that the s390 port should follow whatever convention
is established by other ports.  I just do not quite understand what
benefit three options bring if two of them are synonymous for all 
intents and purposes ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: S/390: -march= and -mcpu= options

[Eric Christopher]

On Mon, 2002-12-23 at 20:52, David Edelsohn wrote:
> >>>>> Daniel Jacobowitz writes:
> 
> Daniel> Oh, now that's a bit of a stretch.  From a quick inventory of the
> Daniel> current head sources, the only architectures which implement both
> Daniel> -march and -mtune are ARM, CRIS, and MIPS.  I know for a fact that
> Daniel> -mcpu is deprecated on MIPS targets; in fact I think it's been removed
> Daniel> since I last checked, since it isn't in TARGET_OPTIONS any more.  The
> Daniel> consensus among the MIPS maintainers was that it caused more confusion
> Daniel> than simplicity.
> 
> -march: arm, cris, i386, mips
> -mcpu: alpha, arc, arm, c4x, cris, frv, h8300, i386, rs6000, s390, sparc
> -mtune: alpha, arm, cris, mips, rs6000, sparc
> 
> 	I would not consider the current Mips port in the FSF sources to
> be a good precedent for GCC ports.
> 

I would. In fact, I chose arch and tune at the suggestion of the other
maintainers and the SC as the correct usage for ports "going forward".

-eric

-- 
Yeah, I used to play basketball...

Re: S/390: -march= and -mcpu= options

[Richard Henderson]

On Mon, Dec 23, 2002 at 11:52:52PM -0500, David Edelsohn wrote:
> -march: arm, cris, i386, mips
> -mcpu: alpha, arc, arm, c4x, cris, frv, h8300, i386, rs6000, s390, sparc
> -mtune: alpha, arm, cris, mips, rs6000, sparc
> 
> 	I would not consider the current Mips port in the FSF sources to
> be a good precedent for GCC ports.

I would.

The reason why I don't like -mcpu is that it has an ambiguous history.
It means one thing on x86 and another on sparc.  Given this history,
it does us no good whatsoever to keep it around in any form.

IMO -march/-mtune are sufficient.


r~

Re: S/390: -march= and -mcpu= options

[Daniel Jacobowitz]

On Mon, Dec 23, 2002 at 11:52:52PM -0500, David Edelsohn wrote:
> >>>>> Daniel Jacobowitz writes:
> 
> Daniel> Oh, now that's a bit of a stretch.  From a quick inventory of the
> Daniel> current head sources, the only architectures which implement both
> Daniel> -march and -mtune are ARM, CRIS, and MIPS.  I know for a fact that
> Daniel> -mcpu is deprecated on MIPS targets; in fact I think it's been removed
> Daniel> since I last checked, since it isn't in TARGET_OPTIONS any more.  The
> Daniel> consensus among the MIPS maintainers was that it caused more confusion
> Daniel> than simplicity.
> 
> -march: arm, cris, i386, mips
> -mcpu: alpha, arc, arm, c4x, cris, frv, h8300, i386, rs6000, s390, sparc
> -mtune: alpha, arm, cris, mips, rs6000, sparc
> 
> 	I would not consider the current Mips port in the FSF sources to
> be a good precedent for GCC ports.

That leaves ARM and CRIS implementing the semantics you were calling
"standardized".  What some of those other architectures choose to do
with the values varies quite a bit, as I recall from the last time I
was looking at this (the ill-fated --with-cpu patch, posted nine times
with a little feedback but no review before I gave up).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: S/390: -march= and -mcpu= options

[David Edelsohn]

>>>>> Daniel Jacobowitz writes:

Daniel> Oh, now that's a bit of a stretch.  From a quick inventory of the
Daniel> current head sources, the only architectures which implement both
Daniel> -march and -mtune are ARM, CRIS, and MIPS.  I know for a fact that
Daniel> -mcpu is deprecated on MIPS targets; in fact I think it's been removed
Daniel> since I last checked, since it isn't in TARGET_OPTIONS any more.  The
Daniel> consensus among the MIPS maintainers was that it caused more confusion
Daniel> than simplicity.

-march: arm, cris, i386, mips
-mcpu: alpha, arc, arm, c4x, cris, frv, h8300, i386, rs6000, s390, sparc
-mtune: alpha, arm, cris, mips, rs6000, sparc

	I would not consider the current Mips port in the FSF sources to
be a good precedent for GCC ports.

David

Re: S/390: -march= and -mcpu= options

[Daniel Jacobowitz]

On Mon, Dec 23, 2002 at 11:14:35PM -0500, David Edelsohn wrote:
> >>>>> Ulrich Weigand writes:
> 
> Ulrich> David Edelsohn wrote:
> >> First there are backward compatibility issues in a complete s390
> >> port.
> 
> Ulrich> Which issues are you thinking of?  Up to now, the s390 port has
> Ulrich> never accepted any of the options under discussion now, so there
> Ulrich> are no old options to be compatible with ...
> 
> 	Compatibility with pre-G5 processors.  I am not referring to
> command-line compatibility.

Yes, but that's not what I meant by compatibility.

> >> Second, the people who participated in the earlier discussion
> >> agreed that there should be a shorthand.
> 
> Ulrich> Why shouldn't -march=z900 be enough?  The compiler has to 
> Ulrich> select *some* scheduling model, and it would be silly to
> Ulrich> schedule for a CPU the generated code cannot run on, thus
> Ulrich> it would be reasonable to default to -mtune=z900 if
> Ulrich> -march=z900 is given.  What should then be the difference 
> Ulrich> between -mcpu=z900 and -march=z900?
> 
> 	Your premise is wrong.  z900 64-bit code cannot run on a G5
> system, but G5 code can run on a z900 system.  One may want to compile
> applications tuned for systems with the widest deployment or tuned for
> newest systems.  Commercial compilers from hardware vendors like HP, IBM,
> SGI, Sun, etc. frequently do the latter -- one wants applications to run
> best on new hardware while remaining backward compatible with the earliest
> architecture still supported.

Sure.  What Ulrich is saying is that -march=z900 without any -mtune
option should imply -mtune=z900.  I think that's reasonable.

> 	It would be useful to have consistent options in all GCC ports.
> -march=, -mtune=, and -mcpu= have individual merit and well-defined
> meaning.  It would be helpful if the s390 port adopted the same
> conventions as other ports, especially because it is not difficult to
> implement the semantics of the three options.

Oh, now that's a bit of a stretch.  From a quick inventory of the
current head sources, the only architectures which implement both
-march and -mtune are ARM, CRIS, and MIPS.  I know for a fact that
-mcpu is deprecated on MIPS targets; in fact I think it's been removed
since I last checked, since it isn't in TARGET_OPTIONS any more.  The
consensus among the MIPS maintainers was that it caused more confusion
than simplicity.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: S/390: -march= and -mcpu= options

[David Edelsohn]

>>>>> Ulrich Weigand writes:

Ulrich> David Edelsohn wrote:
>> First there are backward compatibility issues in a complete s390
>> port.

Ulrich> Which issues are you thinking of?  Up to now, the s390 port has
Ulrich> never accepted any of the options under discussion now, so there
Ulrich> are no old options to be compatible with ...

	Compatibility with pre-G5 processors.  I am not referring to
command-line compatibility.

>> Second, the people who participated in the earlier discussion
>> agreed that there should be a shorthand.

Ulrich> Why shouldn't -march=z900 be enough?  The compiler has to 
Ulrich> select *some* scheduling model, and it would be silly to
Ulrich> schedule for a CPU the generated code cannot run on, thus
Ulrich> it would be reasonable to default to -mtune=z900 if
Ulrich> -march=z900 is given.  What should then be the difference 
Ulrich> between -mcpu=z900 and -march=z900?

	Your premise is wrong.  z900 64-bit code cannot run on a G5
system, but G5 code can run on a z900 system.  One may want to compile
applications tuned for systems with the widest deployment or tuned for
newest systems.  Commercial compilers from hardware vendors like HP, IBM,
SGI, Sun, etc. frequently do the latter -- one wants applications to run
best on new hardware while remaining backward compatible with the earliest
architecture still supported.

	It would be useful to have consistent options in all GCC ports.
-march=, -mtune=, and -mcpu= have individual merit and well-defined
meaning.  It would be helpful if the s390 port adopted the same
conventions as other ports, especially because it is not difficult to
implement the semantics of the three options.

David

Re: S/390: -march= and -mcpu= options

[Ulrich Weigand]

David Edelsohn wrote:

>First there are backward compatibility issues in a complete s390
>port.

Which issues are you thinking of?  Up to now, the s390 port has
never accepted any of the options under discussion now, so there
are no old options to be compatible with ...

>Second, the people who participated in the earlier discussion
>agreed that there should be a shorthand.

Why shouldn't -march=z900 be enough?  The compiler has to 
select *some* scheduling model, and it would be silly to
schedule for a CPU the generated code cannot run on, thus
it would be reasonable to default to -mtune=z900 if
-march=z900 is given.  What should then be the difference 
between -mcpu=z900 and -march=z900?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: S/390: -march= and -mcpu= options

[Gabriel Dos Reis]

David Edelsohn <dje@watson.ibm.com> writes:

| 	The point is think about this from the user perspective, not a
| geek perspective.  The complexity of the options should scale with the
| expertise necessary to use them.  -Wall is just shorthand for a useful
| subset of GCC -Wxxx options after all.

Except that the specification of -Wall is controversial ;-)

-- Gaby

Re: S/390: -march= and -mcpu= options

[David Edelsohn]

>>>>> Daniel Jacobowitz writes:

Daniel> Then why is -mcpu= necessary, if there is no backwards compatibility
Daniel> issue on S/390?  It's a shorthand for -march=z900 -mtune=z900, if I'm
Daniel> reading your comments above correctly.

	First there are backward compatibility issues in a complete s390
port.

	Second, the people who participated in the earlier discussion
agreed that there should be a shorthand.

	When not accepting the defaults, most GCC end-users want a single
option which means "give me optimal code for the processor on which I will
be running the application".  Software distributors or system
administrators are more likely to want backward compatibility with optimal
tuning for the latest installed base of systems and are willing to
investigate options.  And computer geeks will test all combinations.

	Why force most users to set multiple commandline options for the
common case?  That's bad interface design and asking for users to complain
about poor performance of GCC-compiled applications due to user error.

	The point is think about this from the user perspective, not a
geek perspective.  The complexity of the options should scale with the
expertise necessary to use them.  -Wall is just shorthand for a useful
subset of GCC -Wxxx options after all.

David

Re: S/390: -march= and -mcpu= options

[Daniel Jacobowitz]

On Mon, Dec 23, 2002 at 02:52:24PM -0500, David Edelsohn wrote:
> >>>>> Hartmut Penner writes:
> 
> > I agree, mtune is more intuitive. My decision for mcpu was based on the
> > fact, that it is used in most backend, and especially on the x86 port. If
> > there is a agreement on the mailing list, that mtune is preferred, I would
> > change it for S/390 accordingly.
> 
> 	The original discussion did reach consensus, but not what has been
> discussed in this thread.  The agreement is that three options are
> necessary: -march=, -mtune=, and -mcpu=.
> 
> -march=		Enable optional architecture features for a particular CPU
> 		(e.g., GCC target_flags).
> 
> -mtune=		Choose a scheduling model for a particular CPU.
> 
> -mcpu=		Choose both architecture features and scheduling model.
> 
> 
> To compile with backwards compatibility for MMX but tuned for the latest
> Pentium4 processor pipelin, one would use
> 
> 	gcc -march=pentium-mmx -mtune=pentium4
> 
> To compile with all options optimally set for Athlon, one would use
> 
> 	gcc -mcpu=athlon
> 
> In the zSeries case, to compile with backwards compatibility for G5 but
> tuned for z900, one would use
> 
> 	gcc -march=g5 -mtune=z900
> 
> To utilize all z900 features, one would use
> 
> 	gcc -mcpu=z900

Then why is -mcpu= necessary, if there is no backwards compatibility
issue on S/390?  It's a shorthand for -march=z900 -mtune=z900, if I'm
reading your comments above correctly.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: S/390: -march= and -mcpu= options

[David Edelsohn]

>>>>> Hartmut Penner writes:

> I agree, mtune is more intuitive. My decision for mcpu was based on the
> fact, that it is used in most backend, and especially on the x86 port. If
> there is a agreement on the mailing list, that mtune is preferred, I would
> change it for S/390 accordingly.

	The original discussion did reach consensus, but not what has been
discussed in this thread.  The agreement is that three options are
necessary: -march=, -mtune=, and -mcpu=.

-march=		Enable optional architecture features for a particular CPU
		(e.g., GCC target_flags).

-mtune=		Choose a scheduling model for a particular CPU.

-mcpu=		Choose both architecture features and scheduling model.


To compile with backwards compatibility for MMX but tuned for the latest
Pentium4 processor pipelin, one would use

	gcc -march=pentium-mmx -mtune=pentium4

To compile with all options optimally set for Athlon, one would use

	gcc -mcpu=athlon

In the zSeries case, to compile with backwards compatibility for G5 but
tuned for z900, one would use

	gcc -march=g5 -mtune=z900

To utilize all z900 features, one would use

	gcc -mcpu=z900

David

Re: S/390: -march= and -mcpu= options

[Alexandre Oliva]

On Dec 23, 2002, "Hartmut Penner" <HPENNER@de.ibm.com> wrote:

> If there is a agreement on the mailing list, that mtune is
> preferred, I would change it for S/390 accordingly.

That's the recommended for new ports.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: S/390: -march= and -mcpu= options

[Hartmut Penner]

>  >Hello,
>  > this patch introduce the -march= and -mcpu= options.
>  > Right now, only three systems are distinguished, g5, g6 and z900.

> I would suggest, like some ports already have, using the much more
> intuitive "-mtune" instead of "-mcpu".  I was going to submit a patch
> to add the "-mtune" synonym to the x86 port.

I agree ,mtune is more intuitive. My decision for mcpu was based on the
fact,
that it is used in most backend, and especially on the x86 port. If there
is a
agreement on the mailing list, that mtune is preferred, I would change it
for
S/390 accordingly.

Mit freundlichem Gruß / Best regards,

Hartmut Penner