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

[Eirik Byrkjeflot Anonsen <eirik at opera dot com>]

Jakub Jelinek <jakub@redhat.com> writes:

> On Tue, Feb 08, 2011 at 08:01:17PM +0100, Jan Kratochvil wrote:
>> On Tue, 08 Feb 2011 18:23:35 +0100, H.J. Lu wrote:
>> > On Tue, Feb 8, 2011 at 9:10 AM, Jan Kratochvil
>> > <jan.kratochvil@redhat.com> wrote:
>> > > Current binutils HEAD:
>> > > -march | -mtune Â| nopl used? Â| after the attached patch: nopl used?
>> > > Â-  Â|  -   |  Âno    | no
>> > > Âi686 Â| -/i686 Â|  Âno    | no
>> > > Â- Â Â| Â i686 Â| Â yes = BUG | no
>> > > Âcore2 | -/core2 |  yes    | yes
>> > > Â- Â Â| Â core2 | Â yes = BUG | no
>> > >
>> > > => Currently suppressing -march now produces more advanced code output, this
>> > > Â does not seem correct to me.
>> > 
>> > By default, x86 assembler assumes that the target processor accepts
>> > any instructions.  You can restrict ISA sets by -march and .arch directive.
>> 
>> Aha, in such case the system build should use some specific -march anyway and
>> not just to disable `nopl'.
>
> Not very easily, because lots of packages will contain SSE/SSE2/.../AVX etc.
> insns in inline asm etc. and use it conditionally based on used CPU (or with target
> attribute switching among functions).  So IMHO requiring that -march= is passed to
> gas whenever -mtune= is used doesn't look like a good idea.
>
> 	Jakub

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".

In the case you describe above it sounds like you want the assembler to
never automatically insert instructions outside of a certain instruction
set, but still allow the use of explicit instructions outside that set.

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