Re: PATCH: Add --with-arch=cpu (Re: Should gcc configurted for CPU to generate code for CPU by default?)

[Michael Eager <eager at mvista dot com>]

"H. J. Lu" wrote:
> 
> On Fri, Jul 19, 2002 at 02:15:49PM -0400, Daniel Jacobowitz wrote:
> >
> > Right now, we have a handful of architectures that support --with-cpu=.
> > They all do it in different ways.  Most don't recognize it at all.
> > What I am suggesting is that the driver (gcc.c) should recognize
> > -march= and -mcpu= if TARGET_{ARCH,CPU}_DEFAULT are defined.  The only
> > thing it should do with them is supply one if none is present.  The
> > backend handles the rest, as before.
> 
> 
> I agree it is not a bad idea. However, different platforms have
> different treatments for TARGET_{ARCH,CPU}_DEFAULT. Some of them treat
> them as bit masks, while others treat them as indexes. Unify them or
> not belongs to a different discussion.
> 
> While we are on this topic, we have -march, -mcpu and -mtune for
> different backends. They may not have the same meaning even when the
> option name is the same. It is particularly true for -mcpu. I don't
> see if we can unify them without breaking backward compatibility.


Let me jump in here, even if a bit late.

Most of the architecture/cpu processing in config.gcc is pretty inconsistent
and jumbled.  As you point out the interpretation of the -march, -mcpu, and 
-mtune is not consistent across all architectures.   

I don't think that the way to address this inconsistency is to add yet 
another option.  The architecture of is the first component of a target 
triple/quad.  If --target=i586-montavista-linux, there is no 
need to also specify --with-arch=i586.

The interpretation of --with-cpu, for most architectures, is to specify
a specific processor model within an architecture.  Not all architectures
accept this option.  Worse, not all architectures use the same set of
flags to pass this information into the compiler.  For example, MIPS uses
target_cpu_default to indicate whether or not gas is being used, not 
which processor is the default.

[As a small bit of background, some time ago I developed a patch for 
gcc-2.95.3 for MIPS which accepted --with-cpu, separated the gas flags from 
the default cpu type, and correctly configured the default processor.  
Unfortunately,  I never got around to porting it to the CVS head.]

Daniel's suggestion that the driver, not cc1, handle the --with-cpu option
is interesting.  This would also address another problem.  Although cc1 
knows the default cpu, the driver doesn't.  This means that this cannot
be passed on to as.   This is needed in the cases either when the assembler
should generate different op codes for different processor variants, or 
flag instructions which are not valid on the target processor.  This works
if the user specifies --mcpu= on the command line, but it doesn't work if
gcc is configured with --with-cpu=.

So, with some trepidation, let me suggest the following:

1)  target_cpu_flags be created to capture options, like --gas=yes.
2)  target_cpu_default have the processor flags.
3)  target_cpu_name is the name of the processor specified in --with-cpu.
4)  export each of these names to config.h so that they can be used 
    either by cc1 or gcc
5)  add a specs file option to generate the target_cpu_name so that
    this info can be passed either to cc1, as or other components,
    as needed.

Comments?  Suggestions?



--
Michael Eager     eager@mvista.com	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085