From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhTf6-0008Dh-U0 for qemu-devel@nongnu.org; Thu, 23 Oct 2014 21:27:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhTf0-0001J1-Ou for qemu-devel@nongnu.org; Thu, 23 Oct 2014 21:27:28 -0400 Received: from mga09.intel.com ([134.134.136.24]:24453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhTez-0001FE-Vq for qemu-devel@nongnu.org; Thu, 23 Oct 2014 21:27:22 -0400 Date: Fri, 24 Oct 2014 09:27:16 +0800 From: Chao Peng Message-ID: <20141024012716.GB3135@pengc-linux.bj.intel.com> References: <1414033363-31032-1-git-send-email-chao.p.peng@linux.intel.com> <20141023194923.GA25413@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141023194923.GA25413@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [PATCH] target-i386: add Intel AVX-512 support Reply-To: Chao Peng List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel@nongnu.org, Vadim Rozenfeld , Paolo Bonzini , Laszlo Ersek , Andreas =?iso-8859-1?Q?F=E4rber?= On Thu, Oct 23, 2014 at 05:49:23PM -0200, Eduardo Habkost wrote: > On Thu, Oct 23, 2014 at 11:02:43AM +0800, Chao Peng wrote: > [...] > > @@ -707,6 +714,24 @@ typedef union { > > } XMMReg; > > > > typedef union { > > + uint8_t _b[32]; > > + uint16_t _w[16]; > > + uint32_t _l[8]; > > + uint64_t _q[4]; > > + float32 _s[8]; > > + float64 _d[4]; > > +} YMMReg; > > + > > +typedef union { > > + uint8_t _b[64]; > > + uint16_t _w[32]; > > + uint32_t _l[16]; > > + uint64_t _q[8]; > > + float32 _s[16]; > > + float64 _d[8]; > > +} ZMMReg; > > + > > +typedef union { > > uint8_t _b[8]; > > uint16_t _w[4]; > > uint32_t _l[2]; > > @@ -725,6 +750,20 @@ typedef struct BNDCSReg { > > } BNDCSReg; > > > > #ifdef HOST_WORDS_BIGENDIAN > > +#define ZMM_B(n) _b[63 - (n)] > > +#define ZMM_W(n) _w[31 - (n)] > > +#define ZMM_L(n) _l[15 - (n)] > > +#define ZMM_S(n) _s[15 - (n)] > > +#define ZMM_Q(n) _q[7 - (n)] > > +#define ZMM_D(n) _d[7 - (n)] > > + > > +#define YMM_B(n) _b[31 - (n)] > > +#define YMM_W(n) _w[15 - (n)] > > +#define YMM_L(n) _l[7 - (n)] > > +#define YMM_S(n) _s[7 - (n)] > > +#define YMM_Q(n) _q[3 - (n)] > > +#define YMM_D(n) _d[3 - (n)] > > + > > #define XMM_B(n) _b[15 - (n)] > > #define XMM_W(n) _w[7 - (n)] > > #define XMM_L(n) _l[3 - (n)] > > @@ -737,6 +776,20 @@ typedef struct BNDCSReg { > > #define MMX_L(n) _l[1 - (n)] > > #define MMX_S(n) _s[1 - (n)] > > #else > > +#define ZMM_B(n) _b[n] > > +#define ZMM_W(n) _w[n] > > +#define ZMM_L(n) _l[n] > > +#define ZMM_S(n) _s[n] > > +#define ZMM_Q(n) _q[n] > > +#define ZMM_D(n) _d[n] > > + > > +#define YMM_B(n) _b[n] > > +#define YMM_W(n) _w[n] > > +#define YMM_L(n) _l[n] > > +#define YMM_S(n) _s[n] > > +#define YMM_Q(n) _q[n] > > +#define YMM_D(n) _d[n] > > + > > I am probably not being able to see some future use case of those data > structures, but: why all the extra complexity here, if only ZMM_Q and > YMM_Q are being used in the code, and the only place affected by the > ordering of YMMReg and ZMMReg array elements are the memcpy() calls on > kvm_{put,get}_xsave(), where the data always have the same layout? > Thanks Eduardo, then I feel comfortable to drop most of these macros and only keep YMM_Q/ZMM_Q left. As no acutal benefit for ordering, then I will also make these two endiness-insensitive. Chao