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 06C633858D39 for ; Wed, 13 Dec 2023 09:13:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 06C633858D39 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 06C633858D39 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=1702458808; cv=none; b=EYZQuoVNbO4paL1j139K6/+iPA/j1Vxl/T9n/JbiQgvZPP+z+G8SYAIUTbU/usDcbZVu8jxQoW/06B/chk0rJxG4V3blNfiJCPPO3bHW1vpi5k/YJ0l0q4ANk3AgRjcUsRs/+ByA+CJ9VZGVOcfGuwc00qmLwLm+r7HdxS/fYR8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702458808; c=relaxed/simple; bh=KHaCEhN6J2bVrIc2n3Z/Y03XrEO6xog1PRyjAu/vS5M=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=s6t0MfzsE6evnDZ9B7MuCDaBqKwntehnJWLsNbxt417uvC5qkS6kAnLCSmhH5C0jHNHL2fXiTbKbQ4PP8Ly3shsv/WZnGKy9lJNpfFUyuKPEl1AIIsga8tLir9GYSCB9Pfrxcvga3JlKUqb0IQFJQK0E/QHQupSmRbmrLuW1tg4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2c9f85eff28so99758391fa.3 for ; Wed, 13 Dec 2023 01:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1702458802; x=1703063602; 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=2n3mFUljt2kjOL9UCoWcuvbA7nqCpBLpYEEsluN8Gc4=; b=Acs6e2SUKvdVzv/rOVEmU5w9jmvjc982/+zzBIXknHNTzCnTSs92DkI5YxwRBme5mS +vRRFMARFdxJm2SaZyJffdQg0ppCbJxzMjmn7ucyjAi/6GzpmYBQ5RtNA/LzIDcomkK+ p0uWYSGCynVsfT+Xf6JurYEcehLKc6Vav+OEUcAlL4ofk7WLwUcW4cEMixHgfVMAuQUA O1KxNCYU7hRtsppIZ/H64nBR+3LtrWFtpytDCxCqRKpBqF2AyRsKk2MGCdgI7G6Ncq9H 5CSz+fixdPoAGfJ5aAnCVyJGFhHTjx24vMwbomudF4/L8ONXPkSB7Y3HDU9aYHAAgQOo BSkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702458802; x=1703063602; 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=2n3mFUljt2kjOL9UCoWcuvbA7nqCpBLpYEEsluN8Gc4=; b=oK9ZxGW9v1PDHt68OqxYYGBdNKUanxiugvQdbwxIRyY7P4q/3xB1mf+2L7TpLMWFmE j01G9n/iAN/EgzHZqJZ+WaC8Jy0KEt9SMxycvX5+P2PwGAlTmYVyXKioya4C4EyNXTvi tqL5UzAKEf4p8VtLTUJrqQmoCRW6KzS7I6zKr11AUgtK8I5Al+90D+SDevKMLaxvZYGv Kt1f6pCeQv8/V3ZhX+PQHbSmysv2ds7hb+2KDZ1BSmBlZkvTwI7aeb86a598iCe7kd0P nhSlPxC5H/wYXmHH/ZpwySpYYUl27wkF7IXo+bRnoTSowxsrFbSHF3LHKgWGuamKedwq DFCQ== X-Gm-Message-State: AOJu0Yx5JbZ5gqRg2umJP6u0XFwUWltg8NeBnBqDyW9sMaaHe0O4c2Ha kQfQ+K79bGMSB3co+GxZYvN8BMkTIkaadM+xfIco X-Google-Smtp-Source: AGHT+IFijRcRlPKYH3pnKXrTCVtxGftD8kjGhfWElMyGMsQm7cR2m2wbXoPnDjhuQAN+82bP3W0n/A== X-Received: by 2002:ac2:4d91:0:b0:50b:f87a:66a9 with SMTP id g17-20020ac24d91000000b0050bf87a66a9mr3867235lfe.110.1702458802298; Wed, 13 Dec 2023 01:13:22 -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 vk2-20020a170907cbc200b00a1d3e9e888bsm7439744ejc.55.2023.12.13.01.13.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Dec 2023 01:13:22 -0800 (PST) Message-ID: <85a622d4-61f3-4d43-8f34-62615c26a812@suse.com> Date: Wed, 13 Dec 2023 10:13:21 +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> <546c8890-0526-49a3-8310-319358bf55c2@suse.com> <0bb5fbcd-f58e-48ad-a5ee-3413b026f903@suse.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.3 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 13.12.2023 09:35, Cui, Lili wrote: >>>>>>> @@ -14233,6 +14276,12 @@ static bool check_register (const >>>>>>> reg_entry >>>>>> *r) >>>>>>> if (!cpu_arch_flags.bitfield.cpuapx_f >>>>>>> || flag_code != CODE_64BIT) >>>>>>> return false; >>>>>>> + >>>>>>> + /* When using RegRex2, dual VEX/EVEX templates need to be >>>>>>> + marked as >>>>>> EVEX. >>>>>>> + For the later install_template function. */ >>>>>>> + if (current_templates->start->opcode_modifier.vex >>>>>>> + && current_templates->start->opcode_modifier.evex) >>>>>>> + i.vec_encoding = vex_encoding_evex; >>>>>> >>>>>> I'm afraid I don't understand the 2nd sentence of the comment. This >>>>>> may be related to my question regarding cpu_flags_match() further up. >>>>>> >>>>>> The first sentence isn't quite correct either - you don't mark any >>>>>> template here (and you can't, because we don't even know yet which >>>>>> template we're going to use). >>>>>> >>>>>> Finally - do you really need the .evex check here? (I won't exclude >>>>>> that this yields a better diagnostic in certain cases, but this >>>>>> wants clarifying if so.) >>>>>> >>>>> >>>>> If you look at install_template(), you'll see that before this >>>>> function we >>>> need to know if the current encoding is evex. >>>> >>>> "This function" being check_register()? If so, then no, we can't know >>>> up front whether EVEX encoding is going to be needed, as operand >>>> parsing happens ahead of template selection. If instead you mean >>>> "that function" and hence install_template(), then yes, we need to know >> whether to use EVEX there. >>>> Yet how does that result in a need for the .evex check here? (Or >>>> maybe your reply was really to the first of the three parts of my >>>> earlier one?) >>>> >>> >>> Agree with you, put them here is unreasonable. >>> >>> For example >>> >>> vtestps (%r27),%ymm6 >>> >>> we should report unsupported Egpr. But without .evex check, it will report >> "Error: no EVEX encoding for `vtestps'" >>> >>>> But anyway - as said earlier on, using current_templates here looks >>>> wrong in the first place. check_register() deals with only a >>>> register, without regard to the context it is used in (with the sole exception >> of allow_pseudo_reg). >>>> May I remind you that earlier on I already indicated that I suspect >>>> you'll need a new enumerator to put in i.vec_encoding for this new >> purpose? >>>> >>> >>> If we don't put it in check_register(), we need to add a for loop at the >> beginning of the install_template() to check RegRex2. Do you think it is okay? >> Or create a function for it. >>> >>> for (unsigned int op = 0; op < i.operands; op++) >>> { >>> if (i.types[op].bitfield.class != Reg) >>> continue; >>> >>> if (i.op[op].regs->reg_flags & RegRex2) >>> i.vec_encoding = vex_encoding_evex; >>> } >>> >>> if ((i.index_reg && (i.index_reg->reg_flags & RegRex2)) >>> || (i.base_reg && (i.base_reg->reg_flags & RegRex2))) >>> i.vec_encoding = vex_encoding_evex; >> >> As a last resort this may be an option. But until my suggestion wasn't at least >> tried or demonstrated to be worse, I don't think the above would be >> acceptable. >> > >>>> May I remind you that earlier on I already indicated that I suspect >>>> you'll need a new enumerator to put in i.vec_encoding for this new >> purpose? > > Jan, I didn't get your point, I think the enumerator vex_encoding_evex works well, the question is how to filter if Egpr is used in the current instruction, we should make a choice before install_template, whether it's an evex template or a vex template. Well, of course you can make the existing enumerator work, by - see above - adding yet another loop over all operands. In a similar way it may have been possible to avoid the introduction of vex_encoding_evex512. But it is generally better to record the precise reason for requiring a certain encoding / putting in place a certain restriction, i.e. going even beyond the desire to avoid introducing new loops over all operands if at all possible. Here as soon as an eGPR is used, various encodings cannot be used anymore. That's best expressed explicitly. (It might even be that such a new enumerator would help with the REX2 encodings. Recall that I said earlier already that both field and enumerator names aren't fully appropriate anymore. Yet changing them isn't a priority, so we can defer that until after all the APX work has landed.) Jan