This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add -m{arch,tune}=local for x86/x86-64


Hi,

On Wed, 14 Mar 2006, Ian Lance Taylor wrote:

> It seems to me that -march=local is only meaningful for a native
> compiler.  So it seems appropriate to check CROSS_COMPILE, which will be
> defined for a non-native compiler.

Will do.

> > Yes, though that's not a problem (when I was still convinced of the
> > above wrong thing, I argued that a user who would use -march=local on
> > a i386 machine in a cross compiler would get what he deserves, as
> > giving this flag doesn't make sense in a cross environment).  I could
> > have excluded the file for cross compiles, but the other files
> > mentioned in config.host are also not special cased, so it's at least
> > consistent.  I realize that those other files (e.g. host-linux.o)
> > actually have a use also in a cross compiler, unlike my new function.  
> > But suppose someone would go add a new hook (e.g. cache size thingies
> > to optimize bitmap functions or the like), and implement it for only
> > i386.  The natural place now would be driver-i386.c (or a file
> > included in cc1), and then it actually should be included also in
> > cross compilers.  I think the above mentioned #ifdefing around the
> > function might be better.
> 
> I don't think it would be useful to mix something like -march=local,
> which is only meaningful for a native compiler, with something like
> checking cache sizes, which is host-dependent.  I suspect that checking
> cache sizes would most naturally go into files like host-linux.c.  But
> if we really want to be CPU specific, then I think it should go into
> host-i386.c.

Why I thought about cache size is because on x86 type CPUs you can find 
out with the cpuid instruction.  So it wouldn't be in a OS-specific file 
but in a CPU specific file, i.e. a to-be-invented host-i386.c, like you 
said.  I was think to include such hypothetical support together in the 
same file as this march=local support as a matter of pragmatism, as 
otherwise there would be two files which have to be handled slightly 
different in config.host, ala:

case $host in
  ... )
    host_extra_gcc_objs=host-i386.o
    if !cross_compiling
      host_extra_gcc_objs="$host_extra_gcc_objs native-i386.o"
    fi
esac

But that's just hypothetical anyway, so I will do as suggested: wrap the
stuff in CROSS_COMPILING and include it only when not cross compiling in
config.host.

> In fact I think it might be clearer if driver-i386.c were named
> native-i386.c.

Hmm, I named it driver* because it will be included into the gcc driver,
in difference to the compiler proper (cc1*).  driver-native-i386.c seems a 
bit long, perhaps drvntv-i386.c (ugh)?  Saner suggestions?


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]