From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 3CB9C385E002 for ; Fri, 5 Jan 2024 12:15:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3CB9C385E002 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3CB9C385E002 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::22a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704456930; cv=none; b=tmYvAY33InNIJL/sDaJUGFQZ0AnDLe0PSHks5w2FhQA+Jz4VKn7HNZxinGPGVswKjkpt/2tnPU6Ks95Yvd9wC3icapX0JoVJUZlYEP6z1WFWga95L/Tx58jwPv0GbIZ1bDQTGcc1c+yA/lZSYkmUX0wqrULJ8qdn15heIeh7aaM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704456930; c=relaxed/simple; bh=reCbJIKt2L91/FRevMsuy8Q36fXgTQh9YdXqgQFtoJU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=WF7xK1XDdvAAcUkga81QRmyQwIIcc7poUFbzI0NJNmrIIQYTgmLvcANIjrF/644LhPWerO8BWrpoWyUAlCAhs3HOob2pHRE6uZDrFwLT4bx3WAQTPaI/8lDF+klgzUqULFi9O/TdVKtesC9O7Z0qMlZI06GKXvY97XpITjRBpcs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2ccbc328744so17993341fa.3 for ; Fri, 05 Jan 2024 04:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1704456925; x=1705061725; darn=sourceware.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=IIXe8+2RI8hxMmTwqVoI8dFj41FnjTC+qGcNksKfjf8=; b=XW6SDWfQST/rUuo4EYclPGHSstViq4YkMnBPqwrRhjApFkNOOiBOfQELFrp9BgptvO izggt7PAqT/CvAcxRO8r1sRlld1B7qDd44djx1BS/ajMctmnANSSdYw5Ezk54JsNoRJy Z5vTJnABP9NODlHN0l2MfXZpvzL63TPibNwlXNGGYzL7iHvIhWsThM9FdA0dTVIzf+In 8K/dTRbIY+qSuUzxVIhPstIUcCRTJjEtpW0SDpL4vPkJhpqvSYM3ck4+gp9NyFLnMmmF OwyGMpVLTZ4Rp1We5Oik2aaabuE+puQkfu9vgdokoKezoE3V4kVxgUywJPgbnvL2g0wW f8bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704456925; x=1705061725; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IIXe8+2RI8hxMmTwqVoI8dFj41FnjTC+qGcNksKfjf8=; b=Av3hnMFMSjIVVvC3k1XI9nbeDf+RTTghyaKBtFAzp+MX5OTNCVni52MifLYhuVQU6g /5uGEZwPM2GQfzoAKEdA1lUpOqMuqOm5RqIPD0CihYYhy3Rb4Nj9XTAtGwCJENMKh+9i Ki1jHjlRqr8HpbO9qqjWxyvftx2L3KFewHkNdEqe+h4uDzNX52eC2+1XnxV8Xzdm4+OR ZkpJQBO0MTEkas2B1It5ugEgaaQbcnz6Rk+QtS5dB2KnStqcp5gPBbIDgKTlY3lb1/r1 K7l/644AWIgs3l10jT7CVzL47nuimP9sMBECNAg8kZgobajQj0NiT/C131eh5ys+zkC2 fFnQ== X-Gm-Message-State: AOJu0Yz1hvJLj2GdM0/5fbLnP5hzFE8/4CCZbzfQxP9nDIrPsq7nd1vR hXqofmopWwQd0XkuAfqL7ii0Xkf+f25W8CICCKbzUi87fw== X-Google-Smtp-Source: AGHT+IEdawSkwiffFBSr0IbBSJfHDYPeP6HAvoGOwuDk35MW58eW+fC6JW5gWNp0nsUNsqufZFLz6w== X-Received: by 2002:a2e:888a:0:b0:2cc:f41d:9304 with SMTP id k10-20020a2e888a000000b002ccf41d9304mr1106374lji.90.1704456925478; Fri, 05 Jan 2024 04:15:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ck19-20020a056e02371300b0035fec699584sm467844ilb.13.2024.01.05.04.15.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Jan 2024 04:15:25 -0800 (PST) Message-ID: Date: Fri, 5 Jan 2024 13:15:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Binutils Cc: "H.J. Lu" , Lili Cui From: Jan Beulich Subject: [PATCH] x86: add missing APX logic to cpu_flags_match() Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3026.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: As already indicated during review, we can't get away without certain adjustments here: Without these, respective {evex}-prefixed insns are assembled to APX encodings even when APX_F is turned off. While there also extend the respective comment in the opcode table, to explain why this construct is used. --- Strictly speaking we could go with just cpuid|APX_F in the templates, with the assertions dropped and instead an "else" added. But I think we're better off this way, for being less prone to introducing mistakes later on. The resulting diagnostics aren't quite correct (because of not mentioning the {evex} prefix, which really is what's the problem there), but improving diagnostics is a wider topic anyway. --- a/gas/config/tc-i386.c +++ b/gas/config/tc-i386.c @@ -1940,6 +1940,30 @@ cpu_flags_match (const insn_template *t) any.bitfield.cpuavx512vl = 0; } } + + /* Dual non-APX/APX templates need massaging from what APX_F() in the + opcode table has produced. While the direct transformation of the + incoming cpuid&(cpuid|APX_F) would be to cpuid&(cpuid) / cpuid&(APX_F) + respectively, it's cheaper to move to just cpuid / cpuid&APX_F + instead. */ + if (any.bitfield.cpuapx_f + && (any.bitfield.cpubmi || any.bitfield.cpubmi2 + || any.bitfield.cpuavx512f || any.bitfield.cpuavx512bw + || any.bitfield.cpuavx512dq || any.bitfield.cpuamx_tile + || any.bitfield.cpucmpccxadd)) + { + /* These checks (verifying that APX_F() was properly used in the + opcode table entry) make sure there's no need for an "else" to + the "if()" below. */ + gas_assert (!cpu_flags_all_zero (&all)); + cpu = cpu_flags_and (all, any); + gas_assert (cpu_flags_equal (&cpu, &all)); + + if (need_evex_encoding (t)) + all = any; + + memset (&any, 0, sizeof (any)); + } } if (flag_code != CODE_64BIT) --- a/opcodes/i386-opc.tbl +++ b/opcodes/i386-opc.tbl @@ -143,7 +143,13 @@ #define DstVVVV VexVVVV=VexVVVV_DST -// The template supports VEX format for cpuid and EVEX format for cpuid & apx_f. +// The template supports VEX format for cpuid and EVEX format for cpuid & APX_F. +// While therefore we really mean cpuid|(cpuid&APX_F) here, this can't be +// expressed in the generated templates. It's equivalent to just cpuid|APX_F +// anyway, but that is not what we want (as APX_F alone isn't a sufficient +// prereq for such insns). Instead the assembler will massage the CPU specifier +// to the equivalent of either cpuid&(cpuid) or cpuid&(APX_F) (or something +// substantially similar), depending on what encoding was requested. #define APX_F(cpuid) cpuid&(cpuid|APX_F) // The EVEX purpose of StaticRounding appears only together with SAE. Re-use --- a/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l +++ b/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l @@ -13,6 +13,13 @@ .*:25: Error: `andn' is not supported on `x86_64.nobmi' .*:28: Error: `bzhi' is not supported on `x86_64.nobmi2' .*:29: Error: `bzhi' is not supported on `x86_64.nobmi2' +.*:33: Error: .*`andn'.* +.*:34: Error: .*`bzhi'.* +.*:35: Error: .*`kmovw'.* +.*:36: Error: .*`kmovq'.* +.*:37: Error: .*`kmovb'.* +.*:38: Error: .*`ldtilecfg'.* +.*:39: Error: .*`cmpexadd'.* GAS LISTING .* #... [ ]*1[ ]+\# Check illegal 64bit APX EVEX promoted instructions --- a/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s +++ b/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s @@ -27,3 +27,13 @@ .arch .nobmi2 bzhi %r16,%r15,%r11 bzhi %r15,%r15,%r11 + + .arch default + .arch .noapx_f + {evex} andn %r15, %r15, %r11 + {evex} bzhi %r15, %r15, %r11 + {evex} kmovw %k1, %r8d + {evex} kmovq %k1, %r8 + {evex} kmovb %k1, %r8d + {evex} ldtilecfg (%r8) + {evex} cmpexadd %rax, %rcx, (%r8)