From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126891 invoked by alias); 13 Feb 2020 16:46:39 -0000 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 Received: (qmail 126880 invoked by uid 89); 13 Feb 2020 16:46:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:CAMe9rOpaT, H*i:sk:_bE7s2a, H*i:sk:TRQ@mai, H*f:sk:_bE7s2a X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2020 16:46:37 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 33F32AECB; Thu, 13 Feb 2020 16:46:35 +0000 (UTC) Subject: Re: [PATCH] x86: fix AVX* dependencies of ".arch .nosse*" To: "H.J. Lu" Cc: "binutils@sourceware.org" References: <61e23bd1-2a11-b5a7-86aa-06be1ce03a5d@suse.com> <997c4272-d1ab-50cd-56b9-7743270a623c@suse.com> <44c77ef9-29e2-27fb-73ff-2234912405d7@suse.com> From: Jan Beulich Message-ID: <7f635613-d9f1-eb27-5a79-a39135bf2d9c@suse.com> Date: Thu, 13 Feb 2020 16:46:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00295.txt.bz2 On 13.02.2020 17:37, H.J. Lu wrote: > On Thu, Feb 13, 2020 at 8:03 AM Jan Beulich wrote: >> >> On 13.02.2020 16:56, H.J. Lu wrote: >>> On Thu, Feb 13, 2020 at 6:52 AM Jan Beulich wrote: >>>> >>>> On 13.02.2020 15:17, H.J. Lu wrote: >>>>> On Thu, Feb 13, 2020 at 5:44 AM Jan Beulich wrote: >>>>>> >>>>>> On 13.02.2020 12:50, H.J. Lu wrote: >>>>>>> On Thu, Feb 13, 2020 at 1:23 AM Jan Beulich wrote: >>>>>>>> >>>>>>>> Since ".arch .avx*" enables SSE*, disabling SSE* should also disable >>>>>>>> AVX*. Together with 7deea9aad866 ('x86: fix SSE4a dependencies of >>>>>>>> ".arch .nosse*"') I think this makes clear that the whole .arch logic >>>>>>>> needs an overhaul, such that the mechanism to enable features implies >>>>>>>> the reverse operation when disabling any, without having to modify two >>>>>>>> places. Arm64's approach may be worthwhile to consider cloning. >>>>>>>> >>>>>>>> Note that while commit 1848e567343e ("Update x86 CPU_XXX_FLAGS >>>>>>>> handling") introducing the testcase which needs fixing here explicitly >>>>>>>> says "Don't disable AVX nor AVX512 when disabling SSE", I don't see why >>>>>>>> this would be. Furthermore it also says "Don't disable AVX512 when >>>>>>>> disabling AVX", which too has been undone meanwhile (commit 89199bb5a027 >>>>>>>> ["ix86: Disable AVX512F when disabling AVX2"], PR gas/24359). The only >>>>>>>> sensible (consistent) alternative therefore would be to avoid enabling >>>>>>>> SSE* with ".arch .avx*", like is done for SSE* wrt MMX (in turn leading >>>>>>>> to inconsistencies with SSE insns accessing MMX registers). >>>>>>>> >>>>>>> >>>>>>> The intended usages are to build an object: >>>>>>> >>>>>>> 1. Without MMX, but with SSE, AVX and AVX512. >>>>>>> 2. Without SEE nor MMX, but with AVX and AVX512. >>>>>>> 3. Without SSE, MMX, AVX, but with AVX512. >>>>>>> >>>>>>> enforced by assembler. >>>>>> >>>>>> For one - this isn't spelled out anywhere in the docs. And then it's >>>>>> also counter-intuitive. Plus your point 3 isn't true afaict, as per >>>>>> commit 89199bb5a027 mentioned above. >>>>> >>>>> We should revisit it. >>>> >>>> What is the point of a mode like what you outline in 3 above >>> >>> We can use it to build a pure AVX512 object. >> >> But that's not something to be achieved by .arch directives. I >> can see the (at least theoretical) usefulness of such a mode, >> but it should be controlled by something other than .arch, much >> like SSE2AVX mode or SSE insn checking modes also can't be >> controlled this way. > > I think it is doable. Meaning this patch is okay and can go in, while you work on your intended model? Jan