From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id DD3A3394880F for ; Fri, 6 May 2022 16:17:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DD3A3394880F 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 B9DAB7FD96; Fri, 6 May 2022 16:17:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4KvwhJ4bljz3s4w; Fri, 6 May 2022 16:17:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651853856; 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=y1ngcC3FcYgX94jfHmpp9GnJYykXAeZfJUfyVtCPAXY=; b=diT4GbRJcX2REEshpNhiM/N6GWk2eqB5jp8ahhUn9ry0mtzOfUzA6rALVwdOcvhffgScit JPZ8/deZYYqmEq8G3VlF0qJ02vwxoU1Oz7fgXMsCEjkBxOiRKqGbxsxg/7W8wFaAL+k8sW mm1UopOu8mrPwj9mXKgWrBZYpfHeXbfun8Z48IdyXxXdZK2bKpPTPPXcpYIiAO9aNNM1tf 6Ex+dGRM4uosjlWjHqaM9UazUktcqM+vNM8wg6ZNTKgmP9320UQWdxLGr3YsxfX5kx/i5T x79RHqiuksop77MCHBomoSdakjWesAJSYrdyxFj0h51sV7zA3jN2dVfIdRoWUw== 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 32AF92F4EB; Fri, 6 May 2022 16:17:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Fri, 6 May 2022 09:17:35 -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 Content-Language: en-US To: Felix Willgerodt , gdb-patches@sourceware.org References: <20220506121226.137608-1-felix.willgerodt@intel.com> <20220506121226.137608-3-felix.willgerodt@intel.com> From: John Baldwin Subject: Re: [PATCH 2/4] gdb, gdbserver: Add AMX registers. In-Reply-To: <20220506121226.137608-3-felix.willgerodt@intel.com> 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=1651853856; 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=y1ngcC3FcYgX94jfHmpp9GnJYykXAeZfJUfyVtCPAXY=; b=H1PEpOt7BBZSjqrrfvNSl5e1lSdscJ8XDq7jOsI6+jcaex9y9GeM0kNvDLGd6/ALnkpslM 0+NwtPp0KUMDPq+VJ5GgcXi1fvIBKVxVOp36d9i+0nDK655a22cJ457vec2iB2rBbHbfLQ 6s25qjl7PWoFyonax0jtI3zPlSvBUprI/EStwk20D8cEDfX249BE3VhK5eN0a6fgj7YNCZ Sn6G8qE9NTkJCgGxt+G/SGiSbbAmp+VN1th+K03GTm81tq2cNMR6187nDPbn+ri4l8EIRX CLGWvpl1k81WH4IwuHd0X0e+1jy+wB/csc8JE7mjMSUnvPveAcJFwykOy4IUjA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651853856; a=rsa-sha256; cv=none; b=f5I7XKWdnQGCs7KHvgRGUCiYG5ngjy2EuoT6Bsj+N1INJ1MxK5iMrTFrnfx727BMhrBZJA mYd1s3Ed9dSSxfW5Rni+gh7n0J230PJLZ1sw1Ks/LtMiIamwIb0KlkgzG9g5v+1EuEfo15 AzX89VsXLWbDvw2yFxb93rAX6EOAb3aoCDafUcc5A2qwuV9BRX7qh9iMiv9uoOJoN3FdOG 4oGRwtyDVeCcRETg0VthmjPMxXyCQaaagWZ4KsdaB6ECKZDugCrBxFbxIEk+U4l41ep52D /KzP/4E5gJRyel5KEvzigcgg2mu/33rn7EAr8nWqBpZUu94dsnj3XyWMY2MEQQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 06 May 2022 16:17:38 -0000 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