From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PTcsID3I2miapBgAWB0awg (envelope-from ) for ; Mon, 29 Sep 2025 13:56:13 -0400 Received: by simark.ca (Postfix, from userid 112) id 736021E04C; Mon, 29 Sep 2025 13:56:13 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 19F651E04C for ; Mon, 29 Sep 2025 13:56:12 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6DE783858C31 for ; Mon, 29 Sep 2025 17:56:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6DE783858C31 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 944B43858D1E for ; Mon, 29 Sep 2025 17:55:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 944B43858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 944B43858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759168538; cv=none; b=gFZ4ADatj+ELW6i0kirftGNDc5Oiu89Uyavqxm/epis69gzzDljqKjkZTHfNxCqkkuINKkpbwyiJS8z+xphTUs+I1/lKmo4zFOhQctm6D1/3+HUXu8sVeO50vs+FqJLMbFbfDg/sAWzWtw6Ewn96Dq2ARcStjBSTp8zJa5v/tWo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759168538; c=relaxed/simple; bh=2BT+lOGOPWkK5D0lTfriMcaMZeergv1Z+2AfCNMHKj8=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=q/c72IrBDnqryhdPK2NDRUvUPSTD5JQJBZ9wD7yHr2/hlKuT6uZnBDWe1fpgvtWtkEINoT3mDDbVqXXV+olJ2gAktYp5mVzVrKB5N1k+8n8xPkXOz5TgS7e20NKTWxp5mAwWGtgQSAGBBhOaSzYQw0n1UHsk3WHRkBgNv7mCJqA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 944B43858D1E Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-46e48d6b95fso24046285e9.3 for ; Mon, 29 Sep 2025 10:55:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759168537; x=1759773337; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Jb7/umNReKW3gJP3SlbyKEN2BS5PwXW2q1tzPLkPCpk=; b=WIVgReiOfDgbRRrU0+x22yHwshD3gFZxmZ+2O0W9tQUKIAj/NcIoS5stXr+1g2I0Nc pLsJqlKKZlBtyZqDZQGk14QLBi8FPxaJwjwNZ/RMLn3UCbkDDpriTwTrCfNg0YBCrcjG GippJQb0f9EoJuo3AQEio6RTIXRPx8Hy3TN8Lbev5i6JurwZ1OrN+1XX6m0D0bN/jUDm GJ9g39LcwVaLMRApvfXqkbOzonYH0akCvX/oDj86orzYz+r/K5SGP6G9XEYoPwEHBdQM b5NxUGyX0pnRWW6RqmzInJrtWmDhfqqoF6kRO/vEYQPcBh5gzKoRCI7sSRHt5z41uhDr 6eSA== X-Forwarded-Encrypted: i=1; AJvYcCUaZEs86dN2HIbufzXFrfuYyrnxE2XonecXsTVVfKsKsh5A6KlMgOYsAsdLcAUjEhUwu/Gqzp8qO2BcRw==@sourceware.org X-Gm-Message-State: AOJu0YzRbEOQejSJ3TozgjBDvpQ5TGXk+ODy8oeLUnaiSrjPpVUVxsG/ btTF+Fr9rZ6mIy3UVb6zdVzCHC1zzjpBSNrrcE9P3AHv+j24czIt3zrz X-Gm-Gg: ASbGnctymK+izW6nhJcrid1pwswrRQ9uRXUvj9NpG/rMrFVjFajnW9YSg2AUCqKjR+5 FGg5MXh5Vg4s5OOLANaynsxaQdp5gx9LDg9t4SYFethZEtm32Q23gpQk47sLalyMLL5ULNiGnDY A48nvPTouaSF0sgAm6qTdGbKd91okW/HBOkOuasgXcW3ABcODioMOb3NePIEI7AXSl64hWwr8s3 h4C4hl2VOsepHxQoe7LIHjO+75pxr/4XXEqFvkH3a1GpmkuSHU5sK4wWL53w80MczrctC/cGpz2 21Pf1iZYz1gWtH/t87Y0GZtPgGMzZhgwPVoA074L/2p/G6kb74PSHaZJeQitiPXXjLHo+qYHJ00 veEP/xW/eGI1aSD9i1xfUYzSYbZRo+BQkjqgy0ZqbJasYa1e2SFgRrr7J6R0XmH3I1L9PHoGSiQ == X-Google-Smtp-Source: AGHT+IG5HCkWizZP2qRxi9b2sdU6o5Rn+bVkmL5YKHa0wJqHi16jC0jKxM4SusIDrf1HmqSzn8/FFA== X-Received: by 2002:a05:600c:5488:b0:46e:45d3:82fd with SMTP id 5b1f17b1804b1-46e45d384dcmr107708555e9.31.1759168537068; Mon, 29 Sep 2025 10:55:37 -0700 (PDT) Received: from ?IPV6:2001:8a0:faca:8200:c3f4:c15b:bfdd:460? ([2001:8a0:faca:8200:c3f4:c15b:bfdd:460]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-40fb9c32734sm19552133f8f.25.2025.09.29.10.55.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Sep 2025 10:55:36 -0700 (PDT) Message-ID: <5ec9ce76-d614-405f-96e8-f490e035aefb@palves.net> Date: Mon, 29 Sep 2025 18:55:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] gdb: Display fp8 format for AArch64 registers To: Ezra.Sitorus@arm.com, gdb-patches@sourceware.org Cc: eliz@gnu.org, luis.machado.foss@gmail.com References: <20250925211804.21967-1-Ezra.Sitorus@arm.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <20250925211804.21967-1-Ezra.Sitorus@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi! On 2025-09-25 22:18, Ezra.Sitorus@arm.com wrote: > From: Ezra Sitorus > > FP8 introduces 2 new formats: E4M3 and E5M2. This patch aims to add > support for these types in gdb, and then display them in AArch64 > registers. > > So far, this patch series only adds support for these in register printing. > I've picked this, as opposed to printing fp8 variables because (as far > as I'm aware) there is not enough DWARF information to help out with this. > The __mfp8 type has the encoding type 7/unsigned. I'd like to hear any > comments about this approach. Is __mfp8 a real floating type supported by the compiler, or an opaque typedef? Some AMDGPUs have FP8 support, and there, Clang does not expose a real floating point type for this. Instead, we have __amd_fp8_storage_t type that is just a typedef to uint8_t. >From I understand that Aarch64's __mfp8 (and mfloat8_t) is the same. Has that changed since? Assuming it's still the same, since these types are really integers, making variables of such types behave like real floating point variables would be incorrect, in the sense that expressions involving them would behave differently in the actual source code compared to typing them in GDB, like "print a + b" or "print c = 3.3", for example. Since the "floatness" ends up being a presentation issue, for AMDGPU, we added support for these types as gdb Python pretty printers instead. We also added some gdb python functions to manipulate them. See: https://github.com/ROCm/ROCgdb/commit/ad1525387e2ae0a7e46d5b828967ab092c63ecfd > 3/4: adds support for displaying these formats in certain AArch64 registers. Is it really just display? Doesn't the series allow writing to registers with "p \$v0.b.e4m3 = 3.3" (where 3.3 is parsed as a double) or some such? I suppose that might be OK if the type of the register is a built-in GDB type with its own name that is not the same name as of the type the compiler would use for a variable (__mfp8 / mfloat8_t). What about expressions involving FP8 types, like addition, etc. Doesn't that start working with your series as well, if you start from one of those registers (or cast a number to the built-in gdb type)? Like "p \$v0.b.e4m3 + 3.3". > 4/4: adds test cases for these register displays. If it is possible to write to the register, and do arithmetic with it, I think we should have tests for it. Well, even if it isn't possible it would be good to test that too (to make sure it fails instead of doing something bogus). Another (related) detail that I think we should consider when it comes to expressions involving fp8 floats, is that while the interchange format is the same between vendors, thanks to joint multi-vendor work that lead to the OCP spec (https://www.opencompute.org/documents/ocp-8-bit-floating-point-specification-ofp8-revision-1-0-2023-12-01-pdf-1), I believe ARM/Nvidia/AMD FP8 formats behave a bit differently from each other in terms of infinity/saturation/rounding handling, things like that. AMDGPUs even support two FP8 representations FP8-OCP and FP8-FNUZ, see: https://rocm.docs.amd.com/projects/HIP/en/latest/reference/low_fp_types.html Are the AArch64 FP8s added here OCP? I think it we are likely to end up with different versions of these types in libiberty / gdb, so it'd be good to consider making that explicit in the names of the floatformat types in libiberty as well as in the name of the gdb built-in types. Thanks, Pedro Alves