Re: [PATCH] Pass -mtune and -march options to assembler.

[Mark Mitchell <mark at codesourcery dot com>]

Joseph S. Myers wrote:

>>> There are two parts to that recommendation: knowing what
>>> opcodes start with 0xf7, and knowing the alignment of
>>> instructions.  Both of those things are just as knowable in
>>> the compiler as they are in the assembler.

>> But this information are knowable to assembler already, and not available
>> in current GCC version. Do you suggest to add it to GCC?

Yes.

> There is nothing wrong in principle with linking the assembler into the 
> compiler when it becomes useful for the compiler to have information that 
> is much more readily available with existing assembler code, including 
> exact length information for inline asms.

Indeed.

When I said that the assembler has no information other than what the
compiler provides, I meant "no information about the program".  Of
course, the current GNU assembler does have tables that the compiler
doesn't have.  But, there's no theoretical advantage to being an
assembler over being a compiler.  In contrast, the linker does have more
information -- for example, it knows the final addresses that will be
assigned to symbols.

As Dave Korn says, some of these things should perhaps be done in the
linker, rather than the assembler or compiler.  For example, the linker
could go through the entire program and replace NOPs with whatever
instruction is optimal for the target CPU.  Which has the advantage that
even if a library was built for (say) Pentium Pro, it could be be
optimized in this way at link-time for (say) Opteron.  And, the
optimization would then also work with code generated by non-GNU compilers.

Some of these kinds of tricks require being very sure about what is code
and what is data.  The ARM ABI requires compilers to carefully mark
data, even when present in the code segment, so that linkers can
accurately determine what things are instructions and what things are not.

Anyhow, my basic claim is that trying to do optimization in the
assembler will lead to eventual unhappiness.  It deprives the compiler
of possible valuable information (for example, if the assembler changes
opcodes, then perhaps the schedule the compiler generates is not
accurate) and it means that two users with the same exact compiler
binary, but different assembelrs, get different results.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713