From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id F0D003858D32 for ; Mon, 11 Dec 2023 08:43:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0D003858D32 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 F0D003858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::42f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702284203; cv=none; b=NK+4JZvKn1/00fRRQyPO75fffn8UnRO7L14F9bwD6RzKVck+OzWbEcR8QMV5SkdBCPk/CpARCmFcc/Z//9jdwWuia8GYI18XPzJTqOpFljUSSrp3gGh0Z5UUYYaMW16NWqiusNgizEsuDIAp745BYcQotb3xR6vhrIEYISOOYOU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702284203; c=relaxed/simple; bh=srteHw5SmzU+vtgw1I0N0SI09FbNzbEEJ3vHwGxPyUw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=wSBDKxHmxVXppd/tXQb3duxFvJanU+9qROoP52OjWGfAMlHXH+WON3i7w1RZNEuL5TxLfLmAVBKKd+1WwIRhj8tqrnsiuB0zsB0039StY7H5e4XFpb6a0BgquhfqdA1EqkY6diXHL7pe6bNd/ln6aFvE0Z6I4XzV2X+y1jnd3mA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-33628562b88so63200f8f.1 for ; Mon, 11 Dec 2023 00:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1702284201; x=1702889001; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=9dMsrrU9C1zsY1qpvDlhzGE55JS6OjwH4IXUEsqP2SQ=; b=ddkaRqIKCSTRW90/K89UhfaKlANMG7u+TDpWJ+M3QgOi4k/fPZDbGscyQzao43nl24 DMmEq+oW4AOGLvQbFKztzhDjD6vAlQjNVypa9BGK/dm9IxpqdHi1D+K71Fxos9BAFIWS 6tUEtWzPj22MAVFCjFt2K7xQc8Odnh3TCHCxwda4dssHfq8S3A7gc6Nd+10OiPvEV/JW bM7khMSdbJf3/zCEVfJH3SCYCt2neJcIy129w8pbQLB5w3buXFHcHnxwilTKAlbKO4gt osfdGGN0OO2OquDZVsCTWo6QZwHHTeuCr28KD7dN4KyowCNRUuGANMA6eXqfVqvzQ+dy MZQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702284201; x=1702889001; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9dMsrrU9C1zsY1qpvDlhzGE55JS6OjwH4IXUEsqP2SQ=; b=NUi8uZobCe2whLJfrMjddo5120p1T+CesKMJ01O7kUGia9uy2O9usFeyI3rOx+BdVF l1IhTj7nGZXQz/Yt9xY8pmW1MhfaGcpsoQGz8pHXn+fkZD3dH2/NepGVEClAV9dlfd3+ kTM5Is5AlXR8zr+Pkt4OLAwQ5UJQsbTXvS7jQ00rATeT5x6SJeXxnfSm37hHdEJ0ypJh qGzTDbmnyIr35isEwj0z6/IT3pz3msK4YqhVig0uDV8DbLvWuXCuRwZFhZHhCZocob7g 2Jj+xmAwlRUvXsCxhYpvnKC9ecJUSLx+cRhCGH5mTIk+9LRj6dk1sPWPi7Cp0eMCbiXr 5llA== X-Gm-Message-State: AOJu0YxztpTzQG/J+GWKpgeRCoCpIMMuuAfrOHu9N82Uic+0TPT9L0q2 5posb1QMQU6RAQ1/VqKXVzJO X-Google-Smtp-Source: AGHT+IG8rt+8+bjDILJdOXDIGGWSKq0oWu5EcK1khMuSyc3O6Z9E+tNNsAMZhf9+KllPb1FZvdD+Ww== X-Received: by 2002:adf:fa11:0:b0:336:21fb:de22 with SMTP id m17-20020adffa11000000b0033621fbde22mr483793wrr.50.1702284200747; Mon, 11 Dec 2023 00:43:20 -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 e33-20020a5d5961000000b0033346fe9b9bsm8006102wri.83.2023.12.11.00.43.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Dec 2023 00:43:20 -0800 (PST) Message-ID: <28c6845c-adf3-4926-a33d-98b0f2895eae@suse.com> Date: Mon, 11 Dec 2023 09:43:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/9] Support APX GPR32 with extend evex prefix Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "binutils@sourceware.org" References: <20231124070213.3886483-1-lili.cui@intel.com> <20231124070213.3886483-4-lili.cui@intel.com> From: Jan Beulich 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 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3026.5 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: On 11.12.2023 07:16, Cui, Lili wrote: >> On 24.11.2023 08:02, Cui, Lili wrote: >>> + the lower 2 bits of EVEX.aaa must be 0. */ >>> + if ((ins->vex.mask_register_specifier & 0x3) != 0 >>> + || ins->vex.ll != 0 >>> + || ins->vex.zeroing != 0 >>> + || ins->vex.b) >>> + return &bad_opcode; >>> + >>> + /* Fall through. */ >>> case USE_X86_64_TABLE: >> >> Instead of falling through here to go through x86_64_table[] (where in all >> cases the non-64-bit slot is "bad"), can't you avoid that step and go to the >> next step (uniformly the LEN one) right away, saving all those new table entries >> (along the lines of what you do below when processing into >> evex_from_legacy)? >> > > It's not very clear to me here, do you want to add the vex_len_table to delete all entries in i386-dis-evex-x86-64.h? Indeed I think that nothing there is really needed / warranted. The case can be handled with no new table entries at all, I think. > but in this way, there are still some instructions that need to go through x86_64_table[], such as X86_64_VEX_0F38E*. Why would these need special treatment? All EVEX-from-VEX encodings are uniform in being defined for 64-bit code only. >>> @@ -9041,12 +9106,24 @@ get_valid_dis386 (const struct dis386 *dp, >>> instr_info *ins) >>> >>> if (ins->address_mode != mode_64bit) >>> { >>> + if (ins->evex_type != evex_default >>> + || (ins->rex2 & (REX_B | REX_X))) >>> + return &bad_opcode; >> >> What's special about X and B? >> > > For evex_default, the values of these two bits are fixed. Comment added. > > if (ins->address_mode != mode_64bit) > { > /* Report bad for !evex_default and when two fixed values of evex > change.. */ > if (ins->evex_type != evex_default > || (ins->rex2 & (REX_B | REX_X))) > return &bad_opcode; Maybe you didn't get my point: What's wrong with just checking ins->rex2 here as a whole, rather than specially treating two of the bits? >>> @@ -9639,6 +9723,24 @@ print_insn (bfd_vma pc, disassemble_info *info, >> int intel_syntax) >>> if (ins.last_repnz_prefix >= 0) >>> ins.all_prefixes[ins.last_repnz_prefix] = 0xf2; >>> break; >>> + >>> + case PREFIX_NP_OR_DATA: >>> + if (ins.vex.prefix & ~DATA_PREFIX_OPCODE) >> >> ~DATA_PREFIX_OPCODE == 0x99, which likely isn't what you mean here? Do >> you perhaps mean e.g. "> DATA_PREFIX_OPCODE"? (Using the opcodes in >> vex.prefix is questionable anyway, but that's a pre-existing oddity.) >> > > (A || 0) & ~A must be 0. It's hard to read. > > How about this ? This is more intuitive and easy to understand. > > case PREFIX_NP_OR_DATA: > if (ins.vex.prefix == REPE_PREFIX_OPCODE > || ins.vex.prefix == REPNE_PREFIX_OPCODE) > { > i386_dis_printf (info, dis_style_text, "(bad)"); > ret = ins.end_codep - priv.the_buffer; > goto out; > } That's fine with me as well, sure. Jan