Home Original page

[rfc] nopl should not be output on -mtune=i686

Eirik Byrkjeflot Anonsen eirik@opera.com
Thu Feb 10 06:51:00 GMT 2011 
Quentin Neill <quentin.neill.gnu@gmail.com> writes:

> On Wed, Feb 9, 2011 at 12:42 AM, Eirik Byrkjeflot Anonsen
> <eirik@opera.com> wrote:
[...]
>> As I read both the names and the documentation of those two:
>>
>> -march: what processor to generate code for.
>> -mtune: what processor to optimize for.
>>
>> So -mtune does not change which instructions are considered valid, only
>> what is considered "fast".
>>
[...]
>>
>> I can see the potential usefulness of something like:
>>
>> -march = allow instructions for all cpus.
>> -mtune = optimize code for running fast on the most common cpu.
>> -mcompat-arch = do not implicitly generate code that can't run on
>>         the most low-end supported cpu.
>>
>> Thus all three could have different values.  (Yes I made up
>> "-mcompat-arch" to mean "make sure implicitly generated instructions
>> will successfully run on this architecture").
>>
>> None the less, I can certainly see an argument that implicitly
>> generating an instruction outside of the -mtune architecture is unlikely
>> to be "optimized" for that architecture.  :)
>>
>> eirik
>
> Eirik,
>
> I think that the current implementation was meant to have -mtune imply
> your -mcompat-arch, except it was broken, and H.J.'s patches fixed
> that.

Then it is probably good idea to fix the documentation:

`-mtune=CPU'
     Schedule and tune for a particular MIPS cpu.

`-mtune=CPU'
     This option specifies a processor to optimize for. When used in
     conjunction with the `-march' option, only instructions of the
     processor specified by the `-march' option will be generated.

`-mtune=itanium1'
`-mtune=itanium2'
     Tune for a particular IA-64 CPU, ITANIUM1 or ITANIUM2. The default
     is ITANIUM2.

`-mtune=CPU'
     Schedule and tune for a particular MIPS cpu.  Valid CPU values are
     identical to `-march=CPU'.

As I read them, all of them (except itanium, which doesn't really say
much at all) claims that -mtune is about choosing optimal output for a
specific CPU.  The i386 version even seems to say that -mtune does not
restrict the instruction set at all, and you should use -march for that.

As I said above, I think it is reasonable to claim that automatically
generating an instruction that doesn't work on a particular cpu is quite
suboptimal for that cpu.  So it makes sense that -mtune would disallow
it.  But I don't feel the documentation implies that this can be relied
on.

Maybe harmonize all of them to say something like:

"This option specifies a processor to optimize for.  It will also ensure
that the assembler will not implicitly generate instructions that are
invalid for this cpu.  Explicit instructions in the assembly source are
not restricted by this option.  Use -march for that."

Maybe split into two paragraphs.  Maybe add a sentence about "gas does
not currently perform any significant cpu-specific optimizations."
Maybe add a third (architecture-specific) paragraph describing the valid
values.

[...]
> Here is my (limited) understanding of the history, hope it helps.
>
> The -march and -mtune flag names and meanings were adopted from GCC,
> where tuning and generation are major functions.  But the x86
> assembler is not an optimizing assembler (see
> http://sourceware.org/ml/binutils/2010-06/threads.html#00166), it just
> generates what the assembly tells it to.

Quite sensible as long as the assembler is supposed to only be used by a
(optimizing) compiler.  Optimizing twice is probably usually a bad idea.

But opinions on division of labour could change with time.  It may be a
bad idea to lock -mtune to something different than what gcc uses it for
just because we currently think the assembler will not need that option.

(On the other hand, it seems to me that it is unproblematic to have
-mtune IMPLY -mcompat-arch, since that could be considered a strict
subset relation.)

eirik
More information about the Binutils mailing list