From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 09D943858002 for ; Mon, 29 Mar 2021 13:32:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 09D943858002 Received: by mail-ot1-x32b.google.com with SMTP id k14-20020a9d7dce0000b02901b866632f29so12290362otn.1 for ; Mon, 29 Mar 2021 06:32:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=02e99HAZ65YWhyJIvDjwd0d7+e1IM3yc7g1cInqGS4c=; b=O44cMxwAffTYBmdf+aSG21hBB1o8VI1mbalBXvOWyPA37MMjVzxF9jCCjyESZ/34CM 1ELsBrLROfbAGZzDgaWnw7b3chl6BXiXXn3O/VcLPTZm/Rp7Ub+S6K8MjPuOKIs5H5Lz 5qIs1oxC78oeSWf3Z+VY8r9FNIn+9WZRJjB/8zzimljH23Vni/pfHjwjAiKZTDkkLO3q xCJwKZzfZr4tv0eIpvk+ZuafOmyO9054nvdhAs8Apq0HkBZEuCMUkHwjGA9eTGGULFCd m7DFrmSN6jZyxFsxiRtkYqGZQT+fAHRzP1zcGHjYBCTai+pDVYaJCVZdf9L3Z8/eQokf qvCQ== X-Gm-Message-State: AOAM531cmdxjugTXiZygy69NBK67UKYlL7/JAtnG+kDRRhccR6oy7rAo mhNDwROn+oj2/6Eo4sMLsOQYVlauQI4RMt7mvshxnbKVhHQ= X-Google-Smtp-Source: ABdhPJyafVu50Nw8AzeD4csbLTubCOz4Lp0kYPmkgdXawaHa18nRUkZJ7fNu8oJMEI/7f5lpectACJe/ItbYp5gSybM= X-Received: by 2002:a05:6830:1515:: with SMTP id k21mr22826756otp.269.1617024733401; Mon, 29 Mar 2021 06:32:13 -0700 (PDT) MIME-Version: 1.0 References: <287ad145-1fe3-2477-327a-30e8d45a4be7@suse.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 29 Mar 2021 06:31:37 -0700 Message-ID: Subject: Re: [PATCH 4/6] x86: fold SSE2AVX and their base MMX/SSE templates To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3029.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 13:32:15 -0000 On Fri, Mar 26, 2021 at 3:51 AM Jan Beulich wrote: > > This way not only the overall (source) table size shrinks by quite a > bit and the risk of related templates going out of sync with one another > gets lowered, but also (dis)similarities between neighboring templates > become easier to spot. > > Note that for certain SSE2AVX templates this results in benign attribute > changes: > - LDMXCSR and STMXCSR: NoAVX gets set, > - MOVMSKPS, PMOVMSKB, PEXTR{B,W} (register destination), and PINSR{B,W} > (register source): IgnoreSize and NoRex64 get set, > - CVT{DQ,PS}2PD, CVTSD2SS, MOVMSKPD, MOVDDUP, PMOV{S,Z}X{BW,WD,DQ}, and > ROUNDSD: NoRex64 gets set, > - CVTSS2SD, INSERTPS, PEXTRW (memory destination), PINSRW (memory > source), and PMOV{S,Z}X{BD,WQ,BQ}: IgnoreSize gets set. > Similarly the "normal" (non-SSE2AVX) > - non-64-bit CVTS{I,S}2SD forms get NoRex64 set, > - CMP{EQ,ORD,NEQ,UNORD}{P,S}{S,D} forms get C set, > all again in a benign way. > > The remaining differences in the generated table are due to re-ordering > of entries in the course of being folded into templates. > > opcodes/ > 2021-03-XX Jan Beulich > > * i386-opc.tbl (mmx, sse, sse2, sse3, ssse3, sse41, sse42, aes, > pclmul, gfni): New templates. Use them wherever possible. Move > SSE4.1 pextrw into respective section. > * i386-tbl.h: Re-generate. > --- > Considering the setting of C turned out benign for legacy encoding > templates (I did the CMP<>{P,S}{S,D} conversion rather late in the > process, as it was there where I expected problems), it would be an > option to drop the "comm" template parameters, at the expense of further > legacy encoding templates getting C set. An alternative would be to have > i386-gen recognize at least simple & expressions, allowing use of e.g. > ...|&|... in the templates. > > It might further be possible to live with VexVVVV getting set on legacy > encoding templates, which would allow elimination of another template > parameter in a number of cases. > I don't have a preference. Please feel free to do something reasonable. Thanks. -- H.J.