This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Pass -mtune and -march options to assembler.
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Valdimir Volynsky <vvv at ru dot ru>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Dave Korn <dave dot korn dot cygwin at googlemail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 04 Jun 2009 11:29:32 -0700
- Subject: Re: [PATCH] Pass -mtune and -march options to assembler.
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <4A1EBF3A.email@example.com> <firstname.lastname@example.org> <4A203D91.email@example.com> <firstname.lastname@example.org> <4A2058B8.email@example.com> <firstname.lastname@example.org> <4A214E03.email@example.com> <firstname.lastname@example.org> <Pine.LNX.email@example.com> <firstname.lastname@example.org> <4A27FE68.email@example.com> <firstname.lastname@example.org>
Valdimir Volynsky wrote:
> There is few not very important reasons, but in total, IMHO, it's enough
> for not put directives in the .s file now.
> .tune directive not exist in current GNU AS.
We can use autoconf. We already detect lots of features about the
> Current GNU AS process command-line options before reading source file,
> and it's required not so small changes in GNU AS for support .tune.
So, fix the assembler. The ARM assembler reads .march directives from
the .s file, so that should provide some useful examples.
> Cpu-types in GCC and GNU AS not identical. For example: How to translate
> from GCC "pentium-m" "k6-3" and "geode" to GNU AS? So we have to pass only
> part of options.
Why *aren't* they identical? If you're going to have the assembler know
about CPUs, you may as well give it the same set of CPU names that are
in the compiler. That's helpful to users too; having to know one set of
CPU names for -mtune= in the compiler, and a different set for the
assembler is not a good user-interface.
You're treating GAS as an immovable target, but it's not -- we can
> Specs is a good way to pass optimization options, because not required
> to patch binutils.
Specs is an expedient hack -- it's the lowest-effort way to get you
where you want to go right now. If I had to get this into a shipping
product, it's exactly what I'd do. But, I don't think that makes it a
> Optimization - using _all_ ways. Of course, we have to optimize as most
> as possible at GCC level. And optimize remainder at assembler, or even
> linker levels.
Optimization at the linker level is very different from the assembler
level. Optimization in the linker makes sense; the linker has more
information than the compiler/assembler. It's the assembler that I'm
But, if it's not feasible to do the optimizations in the compiler, it is
at least feasible to make the interface between the compiler and
assembler good. I think you should add .mtune to the assembler, make it
accept the same set of cores as GCC (and ignore cores it doesn't
understand, for future backwards compatibility), and then pass along
(650) 331-3385 x713