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

[Quentin Neill]

On Wed, Feb 9, 2011 at 12:42 AM, Eirik Byrkjeflot Anonsen
<eirik@opera.com> wrote:
> 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

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.

He also fixed the fact that PENTIUM_PRO was still generating the alt_
patterns which contained nopl.  The patches we added last year moved
the "nopl" into its own ISA CpuNOP, unbundled it from the i686
processor, added it to others, but didn't actually fix the -march=i686
code generation not to use it.


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.

So -march still means "target arch X" but it does this by restricting
ISAs to that arch (and the default is no restricted ISAs).

The -mtune flag is needed because the assembler generates NOPs for
alignment, and NOPs became ISA specific, so a way to control those was
needed.
-- 
Quentin