From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6343 invoked by alias); 10 Feb 2011 06:51:01 -0000 Received: (qmail 6327 invoked by uid 22791); 10 Feb 2011 06:50:59 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.opera.com (HELO smtp.opera.com) (213.236.208.81) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 Feb 2011 06:50:51 +0000 Received: from trittico.eng.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p1A6oktu014770 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 10 Feb 2011 06:50:47 GMT Received: from eirik by trittico.eng.oslo.osa with local (Exim 4.72) (envelope-from ) id 1PnQMY-00007R-RE for binutils@sourceware.org; Thu, 10 Feb 2011 07:50:46 +0100 From: Eirik Byrkjeflot Anonsen To: binutils@sourceware.org Subject: Re: [rfc] nopl should not be output on -mtune=i686 References: <20110208171044.GA32289@host1.dyn.jankratochvil.net> <20110208190117.GA12119@host1.dyn.jankratochvil.net> <20110208200009.GE13037@sunsite.ms.mff.cuni.cz> <87wrl9hfny.fsf@trittico.eng.oslo.osa> Date: Thu, 10 Feb 2011 06:51:00 -0000 In-Reply-To: (Quentin Neill's message of "Wed, 9 Feb 2011 17:45:00 -0600") Message-ID: <87pqr0gz7d.fsf@trittico.eng.oslo.osa> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00094.txt.bz2 Quentin Neill writes: > On Wed, Feb 9, 2011 at 12:42 AM, Eirik Byrkjeflot Anonsen > 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 =3D allow instructions for all cpus. >> -mtune =3D optimize code for running fast on the most common cpu. >> -mcompat-arch =3D do not implicitly generate code that can't run on >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the most low-end supported cpu. >> >> Thus all three could have different values. =C2=A0(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. =C2=A0:) >> >> 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=3DCPU' Schedule and tune for a particular MIPS cpu. `-mtune=3DCPU' 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=3Ditanium1' `-mtune=3Ditanium2' Tune for a particular IA-64 CPU, ITANIUM1 or ITANIUM2. The default is ITANIUM2. `-mtune=3DCPU' Schedule and tune for a particular MIPS cpu. Valid CPU values are identical to `-march=3DCPU'. 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