This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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.