This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: Expand Broadcast to 3 bits
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "Igor V Tsimbalist" <igor dot v dot tsimbalist at intel dot com>, <binutils at sourceware dot org>
- Date: Thu, 26 Jul 2018 03:15:31 -0600
- Subject: Re: [PATCH] x86: Expand Broadcast to 3 bits
- References: <20180725220507.GA3533@intel.com>
>>> On 26.07.18 at 00:05, <hongjiu.lu@intel.com> wrote:
> --- a/opcodes/i386-opc.h
> +++ b/opcodes/i386-opc.h
> @@ -561,6 +561,17 @@ enum
> #define BOTH_MASKING 3
> Masking,
>
> + /* AVX512 broadcast support. The number of bytes to broadcast is
> + 1 << (Broadcast - 1):
> + 1: Byte broadcast.
> + 2: Word broadcast.
> + 3: Dword broadcast.
> + 4: Qword broadcast.
> + */
> +#define BYTE_BROADCAST 1
> +#define WORD_BROADCAST 2
> +#define DWORD_BROADCAST 3
> +#define QWORD_BROADCAST 4
I don't understand this: Embedded broadcast so far does not allow
byte or word size - why provide for it?
> @@ -650,7 +661,7 @@ typedef struct i386_opcode_modifier
> unsigned int noavx:1;
> unsigned int evex:3;
> unsigned int masking:2;
> - unsigned int broadcast:1;
> + unsigned int broadcast:3;
IOW I'm not convinced this is a useful use of the extra storage required.
It was for a for a purpose that I've shrunk the field to a single bit
recently. I also can't convince myself that overall the change as a whole
is a simplification of the assembler.
Jan