From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id ACE013858D33 for ; Mon, 29 Apr 2024 06:40:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ACE013858D33 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 ACE013858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::22f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714372818; cv=none; b=r4XcZ99MzeAldrPEGyPu392Gj92HC6zOBeKRIgXaWUiVdTf0kP8pYQ0nmYomCrnxzKJCXd752+AsjAECKTYEszDNbhcgiDzF/m8GGF1eDdywLEN5EVjw80oQoewLARzhq9V5MelhC4Y/8Dq9F51zCquChmGLHH3eKDbM2bKTFuA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714372818; c=relaxed/simple; bh=/EufqcLHWrZOCsoa2OMbSsGakYHAqqOop90uXcNfjHo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=QYAoTJ+wg6aoCHDJH96wUN/aRr0oaRNbC7+U5o9m1mRKKjF9GsY3yMPIuTV7cuXYZsC45u4wKtNSTlYj5VPnId6mT0S9Ne57x/Fp4pf9JLI1QXuWK61c5Bjp8r1i1DqkdWhQaO2fynnN9K8pFeGlQneBQe4E6meP1CbpmjrbPic= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2de2f5ca076so45803631fa.0 for ; Sun, 28 Apr 2024 23:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1714372815; x=1714977615; 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=wbSN1IXYj0S/YzA6S8k8xlIwSeCAn6Rlgn4H+FawE08=; b=EHPRnWhtBtWuGIT2+j05OqgUMfVK4AqJM1Grp/RIfg/Bywb9B8Pju+6KQ7jS4ZSEdF tY5zd3E0vOdgTWtLE9/pZSYvMdJxh9PrxCc5z4DBXz0WYNcHmY6b5jZSdWj/mCkrcldc OckBQuvAShh47eYWFjhPL3ELMbcfjXFFpIuphZ8icgC2YCljbs7razTAlucISD5LOd63 qL4JhxIxj8EAgEpNG2DJC1EJWfHWS/MWwbdR6TDykHTRIBJjh9SYi4kLnBrROLDQMA3m xIVoCX/DzFY59U62Pd2Vre6cWKle0PSx6DnbEYf/sf0+nprYEBtU6Fy7/5CRaOXrCHjH k2FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714372815; x=1714977615; 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=wbSN1IXYj0S/YzA6S8k8xlIwSeCAn6Rlgn4H+FawE08=; b=k1aOkbZeZJEdT1lFCjKDqjNNr2JRpIyUJsmjgBRrEUMctu4cYohyIW91bsJ2l6oVep CBebyFnBhdRtU6Qoo8JAFFyvmDyN35NGKBvWvWSFnwbaDDNgQBM3bv0H3VOR0SLS7lbo sPHJrYlKS3envDyvZXBRpTS3l46eSM3l8wc5jni5WlA+8zckwsRJZMwpL8b1EFBtuIL1 zuvfF+Eu9v2Y4xP1Y1CiRjvA68cdBx0PbzBSIy3Fy0tSVUh3rz3xdgJFSdcLrwEqH7Ds nfDRSDWEeJ70TMrA8dYPB5/azrmLYdH8Kp00GfKpXIN1F7+u9jHzmCyE0l1F7ENy7Avr RgRw== X-Forwarded-Encrypted: i=1; AJvYcCU9VsneDlR6Mi+KXfkdqUSG88fXhpH88SmYDWANrCLm3SkeyQWa3EnBFIZYIRnzyJjd8Y0eWSE0Wp28JH7U1+MD7XsI3tsAvA== X-Gm-Message-State: AOJu0Yyhf/T59NAnkqawqzH7MWSmRtZYXCie1noEKCgSWvJsrkOSgBkA FMpBTHlzD2SAAvubKwTAQP73dtYX2KBrqOx23XjMyJlwDLUizbML62SWPzl9aw== X-Google-Smtp-Source: AGHT+IHUZS4yMVNQRZh88v0V1i6SBe5eT9YM+YIaVn6OHvwH6SDXJib00qzcDoB2kTKa8hPF8+vHYA== X-Received: by 2002:a2e:9d49:0:b0:2dc:d2c5:ed0 with SMTP id y9-20020a2e9d49000000b002dcd2c50ed0mr5291025ljj.12.1714372813600; Sun, 28 Apr 2024 23:40:13 -0700 (PDT) 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 b16-20020a05600c4e1000b0041bbec72670sm9085824wmq.39.2024.04.28.23.40.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Apr 2024 23:40:13 -0700 (PDT) Message-ID: <11644d0a-1b51-4c31-82ac-92bb39fd59df@suse.com> Date: Mon, 29 Apr 2024 08:40:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] x86: Drop SwapSources Content-Language: en-US To: "Cui, Lili" Cc: "hjl.tools@gmail.com" , "binutils@sourceware.org" References: <20240424072356.2433122-1-lili.cui@intel.com> <20240424072356.2433122-3-lili.cui@intel.com> <8549a5b2-d8b1-451e-90c1-74ee29dadf3a@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=-3024.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP 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 28.04.2024 06:47, Cui, Lili wrote: >> On 26.04.2024 10:14, Cui, Lili wrote: >>>> On 24.04.2024 09:23, Cui, Lili wrote: >>>>> --- a/gas/config/tc-i386.c >>>>> +++ b/gas/config/tc-i386.c >>>>> @@ -10434,6 +10434,14 @@ build_modrm_byte (void) >>>>> >>>>> switch (i.tm.opcode_modifier.vexvvvv) >>>>> { >>>>> + case VexVVVV_SRC2: >>>>> + if (source != op) >>>>> + { >>>>> + v = source++; >>>>> + break; >>>>> + } >>>>> + /* For XOP: vpshl* and vpsha*. */ >>>>> + /* Fall through. */ >>>>> case VexVVVV_SRC1: >>>> >>>> This falling-through is odd and hence needs a better comment (then >>>> also covering vprot*, which afaict is similarly affected). The reason >>>> for this is the XOP.W-controlled operand swapping, if I'm not >>>> mistaken? In which case perhaps instead of the fall-through here the >>>> logic swapping the operands should replace VexVVVV_SRC2 by >> VexVVVV_SRC1? >>>> >>> >>> Yes, vprot* should be included, and it is related to XOP.W-controlled >> operand swapping, the comments says " /* Only the first two register >> operands need reversing, alongside flipping VEX.W. */ ", But there is >> actually a memory operand, not two register operands. >>> >>> I think VexVVVV_SRC2 makes more sense here, it matches the actual >> situation, we want to use vvvv to encode the first operand. >>> >>> Opcode table: >>> vprot, 0x90 | , XOP, >>> D|Modrm|Vex128|SpaceXOP09|VexVVVV_Src2|VexW0|NoSuf, { RegXMM, >>> RegXMM|Unspecified|BaseIndex, RegXMM } >>> >>> testcase: >>> vprotb (%rax),%xmm12,%xmm15 >>> vprotb %xmm15,(%r12),%xmm0 >> >> VexVVVV_Src2 is appropriate for the latter, yes, but not for the former. That >> uses VexVVVV_Src1 layout. Hence my suggestion to replace the attribute >> when swapping operands. >> > > If replace the Src2VVVV| VexW0 with Src1VVVV| VexW1 and swapping operands. We can put VexVVVV_SRC1 before VexVVVV_SRC2, but we still need to add "(!is_cpu (&i.tm, CpuXOP) || source == op" under VexVVVV_SRC1 , and match_template also needs to be adjusted (I made a simple modification and it still failed, I think continuing like this may go against the original intention). > > switch (i.tm.opcode_modifier.vexvvvv) > { > /* VEX.vvvv encodes the first source register operand. */ > case VexVVVV_SRC1: > if (!is_cpu (&i.tm, CpuXOP) || source == op) > { > v = dest - 1; > break; > } > /* For XOP: vpshl*, vpsha* and vprot*. */ > /* Fall through. */ > /* VEX.vvvv encodes the last source register operand. */ > case VexVVVV_SRC2: > v = source++; > break; > /* VEX.vvvv encodes the destination register operand. */ > case VexVVVV_DST: > v = dest--; > break; > default: > v = ~0; > break; > } > > Do you think we should add a separate patch 4 for XOP that removes the special handling in match_template and completes its template? so we don't have to add special handling for src1vvvv or src2vvvv. This might go against your desire to reduce template size, but it would help simplify the logic. I'd like to know your thoughts. Indeed. You'd effectively revert earlier folding that I did. And the adjustment I suggested earlier ought to be small/simple enough. Jan