From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iowqEwNCeWKhSAUAWB0awg (envelope-from ) for ; Mon, 09 May 2022 12:32:03 -0400 Received: by simark.ca (Postfix, from userid 112) id 428321E21F; Mon, 9 May 2022 12:32:03 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (2048-bit key; secure) header.d=freebsd.org header.i=@freebsd.org header.a=rsa-sha256 header.s=dkim header.b=B/aPlJaM; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 4275A1E01D for ; Mon, 9 May 2022 12:32:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B66BC3856DE0 for ; Mon, 9 May 2022 16:32:01 +0000 (GMT) Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 9BD953858C2C for ; Mon, 9 May 2022 16:31:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BD953858C2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 08EF774380; Mon, 9 May 2022 16:31:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KxmsK6BY9z4hK2; Mon, 9 May 2022 16:31:49 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1652113909; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oSQGhf6J3+BOFSBjFJsSwDNbaPqTbo9gdMkDLOsa1ag=; b=B/aPlJaMBiZcKGXHQsDWy/+Uy052fiTArfwUILutWbF5NtrQKH5s+q9LQrAlN3s5Gg4a3F RDoZasm3y3GNXqkoNLXbKwUHOpF7k+ETjqmWnr0swBy3mPeleyudrnKo4l3MB7xtkrMDeL eKvpb6G7SOeVwuGs3SsFWJwSoNLxzgFcFE2u4rdey1kaCqvk8nsy+Q4xuOyGaZTo7miLX7 hKJ6szaSsqh6Q5WLXpIgg0D1jAMz7wyp0tKgsYy2pvVBbYi8aj0H/YjGUtwWGnC/lRMbz1 d4zVfFuFAXtdqJNth6+gJZj2je9kfvWC5//RmtTr6OqU33PJbRQSVyGRSQakmw== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 6D2976929; Mon, 9 May 2022 16:31:49 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <6c0ec1d6-2190-c919-c90b-af3cd3bf5f83@FreeBSD.org> Date: Mon, 9 May 2022 09:31:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 2/4] gdb, gdbserver: Add AMX registers. Content-Language: en-US To: "Willgerodt, Felix" , "gdb-patches@sourceware.org" References: <20220506121226.137608-1-felix.willgerodt@intel.com> <20220506121226.137608-3-felix.willgerodt@intel.com> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1652113909; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oSQGhf6J3+BOFSBjFJsSwDNbaPqTbo9gdMkDLOsa1ag=; b=KWOgADfwWK6Bc0VCE9/x9GDgVyLgw0oXheo2ANjJhu7Myi82TL2HRhgf8HOYsGXx7frgM5 uT+Sf2y7LQMXxXFM/7eRKhm80paBy36YwAplPBAXlo0NIj9PluXcm2JckMnNIkVMNCp57Z ST0dSJeLOUYFCgeImbvwnM2GMSBD5eEOWkbww3kZX3dYK/DFl0TYpuRv1p5WG02LjvHrcY Bw+CIirx9jZaVezdudg7F9pwYPh9/RqITbqR8p2vlQ4D3T5ptSpmF7Tk6edZrbCojGt6r+ bKz/oa7rNyrjo7IyCpU1UIJHuJS/JPb43nA55oaLRvZ7nT+aJbrcYjMAmqflgA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1652113909; a=rsa-sha256; cv=none; b=p3dyjGMKAMILIQu+A17XDJhxFr2Xr2ao7wJvxc0hGGakTXT6AuQEq4APuVE6GwcvYwLb3I 9y1xZnBf6TR1+L4hMl7PTg/wFzXxxo7xsch/S3TnZ9KBK6mLmxxb1hRARARoN9knlTA2IF B636UjSzXLJXkTexIc3utmABy7bcOWS9YJv2K4V3TGyIEEq+kk/ThSdZ0nFmQ5yfD4leT6 S64phOqKsrpxCpfmuvXKUm+fkiQ5baUXPGxgd4RlmjmxDdScYG3NdjrvSidRmjevv9SrCs 2n4AuWAwWGRaRBnXCrAj5k2F5qhWoLsNTz7FbvovzdSY5is51czMLklgBeW1ZQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 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 Sender: "Gdb-patches" On 5/9/22 12:04 AM, Willgerodt, Felix wrote: >> -----Original Message----- >> From: John Baldwin >> Sent: Freitag, 6. Mai 2022 18:18 >> To: Willgerodt, Felix ; gdb- >> patches@sourceware.org >> Subject: Re: [PATCH 2/4] gdb, gdbserver: Add AMX registers. >> >> On 5/6/22 5:12 AM, Felix Willgerodt via Gdb-patches wrote: >>> Advanced Matrix Extensions (AMX) adds one 64 byte TILECFG register and >>> eight 1024 byte tile registers TMM0, TMM1, ..., TMM7. The tile registers >>> each represent a matrix, whose dimensions are configured via TILECFG. >>> In XSAVE, all tiles are represented in the 8kB TILEDATA section. >>> >>> Future AMX platforms are free to add new palettes, which are >>> run-time configurable partitionings of the TILEDATA space. >>> Currently only palette 0 (initialized zero state) and palette 1 exist. >>> New palettes might change any of the following parameters, which are >> defined >>> in the palette_table (which can be accessed via CPUID): >>> >>> define palette_table[id]: >>> uint16_t total_tile_bytes >>> uint16_t bytes_per_tile >>> uint16_t bytes_per_row >>> uint16_t max_names >>> uint16_t max_rows >>> >>> More information about AMX can be found in the Intel(R) Architecture >>> Instruction Set Extensions Programming Reference, May 2021. >>> >>> The $tilecfg register is implemented as a pseudo register. For convenience >>> it is partitioned as a struct, representing the single configuration options >>> as members. It doesn't show reserved space, as structs can only contain >>> existing data types. To also be able to show the full register, $tilecfg_raw >>> is implemented as a uint512 value. >>> >>> The $tmm0-7 registers are also represented as pseudo registers. This >> allows >>> to only show the actually configured matrix and to omit filling zeros, which >>> greatly increases readability on smaller matrices. A raw $tiledata register >>> is implemented as the base for the pseudo registers. >>> >>> When developing this we also considered updating the target description >> at >>> runtime to achieve the dynamic sizing. This however would have required >>> extensive changes to the writing and reading from/to XSAVE. And it >> wouldn't >>> work with gdbserver easily, as there currently is no infrastructure to keep >>> XML target descriptions in sync after the initial transfer. >>> --- >>> diff --git a/gdb/i386-linux-tdep.h b/gdb/i386-linux-tdep.h >>> index 6b3555aa3ea..705c7bcd602 100644 >>> --- a/gdb/i386-linux-tdep.h >>> +++ b/gdb/i386-linux-tdep.h >>> @@ -29,7 +29,7 @@ >>> /* Register number for the "orig_eax" pseudo-register. If this >>> pseudo-register contains a value >= 0 it is interpreted as the >>> system call number that the kernel is supposed to restart. */ >>> -#define I386_LINUX_ORIG_EAX_REGNUM (I386_PKRU_REGNUM + 1) >>> +#define I386_LINUX_ORIG_EAX_REGNUM >> (I386_AMX_TILEDATA_REGNUM + 1) >>> >>> /* Total number of registers for GNU/Linux. */ >>> #define I386_LINUX_NUM_REGS (I386_LINUX_ORIG_EAX_REGNUM + 1) >>> diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c >>> index 8501e12e241..921b24ab60f 100644 >>> --- a/gdb/i386-tdep.c >>> +++ b/gdb/i386-tdep.c >>> @@ -3307,6 +3389,142 @@ i386_mmx_type (struct gdbarch *gdbarch) >>> return tdep->i386_mmx_type; >>> } >>> >>> +/* Construct vector type for TMM registers. */ >>> + >>> +static struct type * >>> +i386_tmm_type (struct gdbarch *gdbarch) >>> +{ >>> + i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep >> (gdbarch); >>> + >>> + if (!tdep->i386_tmm_type) >>> + { >>> + const struct builtin_type *bt = builtin_type (gdbarch); >>> + >>> + uint8_t bytes_per_row = tilecfg_reg::MAX_BYTES_PER_ROW; >>> + uint8_t max_rows = tilecfg_reg::MAX_ROWS; >>> + >>> + /* The type we're building is this: */ >>> +#if 0 >>> + union __gdb_builtin_type_matrix1024i >>> + { >>> + int8_t m_int8[max_rows][bytes_per_row]; >>> + uint8_t m_uint8[max_rows][bytes_per_row]; >>> + int32_t m_int32[max_rows][bytes_per_row/4]; >>> + bfloat16_t m_bfloat16[max_rows][bytes_per_row/2]; >>> + float m_int32[max_rows][bytes_per_row/4]; >>> + }; >>> +#endif >> >> I think it might be better to put this inside of the comment instead of using >> #if 0 >> as a reader might think that code under #if 0 might be intended to be used in >> the >> actual source under some circumstance (e.g. it was old code disabled but not >> removed, or it is some kind of WIP that will be enabled in the future), but this >> is clearly documentation that will never be compiled as part of GDB itself. >> >> (And I think this #if 0 pattern is in some other places in the patch as well?) >> >> -- >> John Baldwin > > Thanks for the feedback. I understand your point. But all pseudo register type > functions in this file (e.g. i386_zmm_type, i386_zmm_type and i386_bnd_type) > use this style of "comment". I don't know the background and am a bit > reluctant to change the style in my patch series. I think that should be done > separately. Oh, yes, sorry, if it is consistent with existing style then best to leave it as-is. -- John Baldwin