This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Pass -mtune and -march options to assembler.
- From: "Valdimir Volynsky" <vvv at ru dot ru>
- To: Mark Mitchell <mark at codesourcery dot com>
- 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 22:09:28 +0400
- Subject: Re: [PATCH] Pass -mtune and -march options to assembler.
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <4A1EBF3A.firstname.lastname@example.org> <email@example.com> <4A203D91.firstname.lastname@example.org> <email@example.com> <4A2058B8.firstname.lastname@example.org> <email@example.com> <4A214E03.firstname.lastname@example.org> <email@example.com> <Pine.LNX.firstname.lastname@example.org> <email@example.com> <4A27FE68.firstname.lastname@example.org>
Mark Mitchell <email@example.com> wrote:
Sorry to keep going around on this -- but why not put
directives in the .s file? You're already conditionalizing on
HAVE_GNU_AS, so you know you're using the GNU assembler.
Command-line options just make it easy for things to get
weirdly out of sync; directives in the .s file keep the
information together. If we must pass this information
to the assembler, at least let's put it in the .s file.
And do it in a way that's table-driven so that adding new
cores to the machine-description doesn't require remembering
to update a separate list of cores to pass to the assembler.
If the assembler doesn't recognize a core name, it can just
ignore the directive.
There is few not very important reasons, but in total,
IMHO, it's enough for not put directives in the .s file
.tune directive not exist in current GNU AS.
New directive will create problems with backward
Standard reaction of assembler to unknown directive -
and exit. Exclusively reaction, IMHO, will not be
supported by binutil
Current GNU AS process command-line options before reading
and it's required not so small changes in GNU AS for
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.
Specs is a good way to pass optimization options, because
not required to patch binutils.
It's not my place to stand in front of the x86 maintainers,
but I still think this whole direction towards optimization
in the assembler is fraught with peril. We've been there,
and we didn't like it.
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.
Professional hosting for everyone - http://www.host.ru