Message ID | 2dbdd49f-2302-4dbc-98ba-0bdaf3c4cad2@suse.com |
---|---|
Headers |
Return-Path: <binutils-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8892E3858014 for <patchwork@sourceware.org>; Fri, 23 Feb 2024 11:27:55 +0000 (GMT) X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id B41293858024 for <binutils@sourceware.org>; Fri, 23 Feb 2024 11:26:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B41293858024 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 B41293858024 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::531 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708687601; cv=none; b=SeCNZ02YYGWUReLCzfDzYqwc3U//DOCQtj29o6/Q/VRT1lz0feJUOcI2gFdYxOHJ7X4Qs2NcN5vLWKKvPGOdUZOeOHf+wFc6l4i1B7IJ2d5Su9puEGb9sa/nXA7esa1+as2wWmYHM4fZRVch50anHj0Z6eWKPVxF82acLxLd1NQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708687601; c=relaxed/simple; bh=OryfhV9RvTPeNxkOPDOvVcmot62cSjoKtmIG1wqp0+c=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=cB83X1wPsM5XXRHqomVXgVS1lN/pLTDLhGSd/T8/EZR5qJ3kmVmbkWN9CNQptMxlKaO0Z1JKccyLgvwOEadr4DJHG3rgeYORtTTfFljQF4JmjzGTNm+8JitptTZdKERgV1TigV2esMCgq4GAUYuDUYOxOUokBtWtG5vhJ8AT/Wg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5656e5754ccso637235a12.0 for <binutils@sourceware.org>; Fri, 23 Feb 2024 03:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1708687598; x=1709292398; 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=OryfhV9RvTPeNxkOPDOvVcmot62cSjoKtmIG1wqp0+c=; b=Ljq4P0N1TGJ8LoAcZ019M4WUrE+yKCXltThtB1sQB5d8+nIx8xkHLw3AmMsIro7R8X nZCaHOTlcVB+bwvxkZaudLS2kJu4U7U9xH6AugjyCtbMyOo/26UmAFFvTVRkZiJc/Fzm e9UKcG3m2pNHQfyc6TzJNe+2itzUUQ4ZOkSp1W4HPFaGfZQKz9ORu/2qJatYVrXYJ48d PbHIxyw2iWqv/dykx46Renijuoz0tl5m5GEBUdSTQJmxqj/QMsif53Q0QeohCw0CwBx2 gWYhbkH/4ASIVXkZFAIdgcOThgjnEo06ROurZSnTWp0a2kA9uER0tUJmK13DIGNhQWC4 G8Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708687598; x=1709292398; 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=OryfhV9RvTPeNxkOPDOvVcmot62cSjoKtmIG1wqp0+c=; b=t1dVvKm8UIprpV9F9dtkl3U8uRRGzXPz2WYJnJPKj1g4vHHAcXR6OK72gyNPkLfbl0 XTcdXh057xvzFV8rA/QCbEX7LifsFSiicb1RrXTgqcMhvvuVyDfTiSpE4PeIDgcfYJ60 ZLCnabXnJmcEDT0VtU+qqFt9GjcXvRE1Tmg1YO14x+J6NmLYkvL9J12Ec5devtMi7aPL UIQDh9h9eqTg1fnZ1Ky1zwVzW/sSOt2QXsFMh6DhkYMdw2qNwsiDPVvPhKb7Ok3XKCpj WnLiW669lfJnHcXzWMYtTj8phK6OTYXsYxAjOpH6Pc83KTWQjheiSR2v8eVxlEYa6Sma PfBQ== X-Gm-Message-State: AOJu0YyOZ1PX9B05wIStidC0bUT7kzMXhE6/ioW3A4nAOADtBtT2/+7l W2JdX9f1aqXAE+3JAYQgKtzHhuRjfRofou19Q7pOl74pKToSkW9dn2wpf4D4njHZZYZc1Yo0U8E = X-Google-Smtp-Source: AGHT+IEuB0dRGbU/oAUorS9wZCl9t5l8MBPY9925FRmK76fD1Zz2QIY0pPL1xPhJP/qcss6g01XoQQ== X-Received: by 2002:a05:6402:3121:b0:565:6e57:fa3d with SMTP id dd1-20020a056402312100b005656e57fa3dmr1011416edb.10.1708687598432; Fri, 23 Feb 2024 03:26:38 -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 w22-20020aa7dcd6000000b00563918a48cfsm6350258edu.40.2024.02.23.03.26.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Feb 2024 03:26:38 -0800 (PST) Message-ID: <2dbdd49f-2302-4dbc-98ba-0bdaf3c4cad2@suse.com> Date: Fri, 23 Feb 2024 12:26:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Binutils <binutils@sourceware.org> Cc: Richard Earnshaw <rearnsha@arm.com>, Marcus Shawcroft <marcus.shawcroft@arm.com>, Nick Clifton <nickc@redhat.com> From: Jan Beulich <jbeulich@suse.com> Subject: [PATCH 0/6] Arm64: (mostly) SVE adjustments 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=-3025.4 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, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> Errors-To: binutils-bounces+patchwork=sourceware.org@sourceware.org |
Series |
Arm64: (mostly) SVE adjustments
|
|
Message
Jan Beulich
Feb. 23, 2024, 11:26 a.m. UTC
Some of the issues addressed here were pointed out before, but only not overly involved ones of those (plus a couple of subsequent findings) are taken care of. The rest is left to people more familiar with the inner workings of the operand type machinery. 1: correct B16B16 indexed bf{mla,mls,mul} 2: check matching operands for predicated B16B16 insns 3: check tied operand specifier in aarch64-gen 4: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate) 5: correct SVE2.1 ld2q (scalar plus scalar) 6: gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1 At least the last patch wants backporting to 2.42. Jan
Comments
On Fri, Feb 23, 2024 at 12:26:37PM +0100, Jan Beulich wrote: > Some of the issues addressed here were pointed out before, but only > not overly involved ones of those (plus a couple of subsequent findings) > are taken care of. The rest is left to people more familiar with the > inner workings of the operand type machinery. > > 1: correct B16B16 indexed bf{mla,mls,mul} > 2: check matching operands for predicated B16B16 insns > 3: check tied operand specifier in aarch64-gen > 4: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate) > 5: correct SVE2.1 ld2q (scalar plus scalar) > 6: gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1 > > At least the last patch wants backporting to 2.42. > > Jan A general comment: we refer to the port as "AArch64", and typically use "aarch64: ..." in commit message headers. I've pushed a further gas/NEWS update on top of your already committed patch 6, to match the change on the release branch. Aside from the aforementioned naming issues and my suggested error message improvement, the remainder of this series looks good to me (although I can't formally approve anything). (If/when this is merged, Srinath can rebase his other fixes on top of this series.)
On 15.03.2024 17:20, Andrew Carlotti wrote: > On Fri, Feb 23, 2024 at 12:26:37PM +0100, Jan Beulich wrote: >> Some of the issues addressed here were pointed out before, but only >> not overly involved ones of those (plus a couple of subsequent findings) >> are taken care of. The rest is left to people more familiar with the >> inner workings of the operand type machinery. >> >> 1: correct B16B16 indexed bf{mla,mls,mul} >> 2: check matching operands for predicated B16B16 insns >> 3: check tied operand specifier in aarch64-gen >> 4: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate) >> 5: correct SVE2.1 ld2q (scalar plus scalar) >> 6: gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1 >> >> At least the last patch wants backporting to 2.42. > > A general comment: we refer to the port as "AArch64", and typically use > "aarch64: ..." in commit message headers. I'm aware of aarch64 being the "arch identifier". I'm not alone though in preferring Arm64 in textual uses - see Linux sources for a prominent example. > I've pushed a further gas/NEWS update on top of your already committed patch 6, > to match the change on the release branch. Aside from the aforementioned > naming issues and my suggested error message improvement, the remainder of this > series looks good to me (although I can't formally approve anything). > > (If/when this is merged, Srinath can rebase his other fixes on top of this > series.) In the absence of arch maintainer comments I've committed the first two patches. I'll reply to your comment on patch 3 separately. Having seen Srinath's patches, I'm actually okay with dropping patches 4 and 5 from here, in favor of his more complete fixes. Once patch 3 is in, he'd need to rebase there, of course. Jan
On 18/03/2024 08:23, Jan Beulich wrote: > I'm aware of aarch64 being the "arch identifier". I'm not alone though in > preferring Arm64 in textual uses - see Linux sources for a prominent > example. This isn't about personal preferences, though, it's about the port name; and that's aarch64. There are good technical reasons for not using arm or anything with that in the name in that this is an entirely separate identifier. There are many configure scripts out there that match arm* (or even, in some cases, arm6* which was a very early implementation of the Arm 32-bit architecture). Having a distinct name really helps with avoiding problems stemming from that. Mixing aarch64 and arm64 in commit tags also makes it more difficult to identify patches relating to the port (and also adds false matches for those searching for the 32-bit arm port). Anyway, please can you use the official tag name in commits in future. R. PS: I'd point out that the x86 port is not called 'intel' either, perhaps for similar reasons.
On 09.05.2024 16:17, Richard Earnshaw (lists) wrote: > > > On 18/03/2024 08:23, Jan Beulich wrote: >> I'm aware of aarch64 being the "arch identifier". I'm not alone though in >> preferring Arm64 in textual uses - see Linux sources for a prominent >> example. > > This isn't about personal preferences, though, it's about the port name; > and that's aarch64. > > There are good technical reasons for not using arm or anything with that > in the name in that this is an entirely separate identifier. There are > many configure scripts out there that match arm* (or even, in some > cases, arm6* which was a very early implementation of the Arm 32-bit > architecture). Having a distinct name really helps with avoiding > problems stemming from that. > > Mixing aarch64 and arm64 in commit tags also makes it more difficult to > identify patches relating to the port (and also adds false matches for > those searching for the 32-bit arm port). > > Anyway, please can you use the official tag name in commits in future. I'll try to keep that in mind, sure. > PS: I'd point out that the x86 port is not called 'intel' either, > perhaps for similar reasons. I find this comparison odd: There are various x86 parts from other vendors. x86-64 wasn't even "invented" by Intel. Jan