Re: [PATCH 4/4] x86: provide a 128-bit VBROADCASTSD pseudo

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Jun 19, 2023 at 12:20 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 16.06.2023 18:59, H.J. Lu wrote:
> > On Fri, Jun 16, 2023 at 12:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >> VBROADCASTSD not supporting 128-bit destinations in any of their AVX,
> >> AVX2, or AVX512F incarnations is presumably because of VMOVDDUP
> >> precisely supporting this very operation. (It is therefore different
> >> from e.g. VPBROADCASTQ, which has no exact equivalent.) Still its
> >> absence has led to people using VPBROADCASTQ as substitution; this could
> >> have been avoided if such a pseudo had been supported from the very
> >> beginning.
> >>
> >> Note that the pseudos try to match what the real instructions would have
> >> used as closely as possible, i.e. VexW0 instead of VexWIG for the AVX
> >> and AVX2 forms as well as AVX2 in the first place for the register
> >> source form.
> >> ---
> >> For being the first example of us supplying such, this is partly RFC. On
> >> top of that a question is also whether to indeed have split AVX/AVX2
> >> templates, when in principle one (allowing for both memory and register
> >> source) could do.
> >>
> >
> > I don't think assembler should invent such instructions.
>
> May I ask about the "why" behind this? If such a pseudo had been there
> from the beginning, an admittedly minor mistake like that corrected by
> gcc commit a4df0ce78d6f likely wouldn't have been made, because no
> special casing of V2DFmode would have been necessary in the first place.
>
> Jan

All x86 instructions should come from the x86 SDM.

-- 
H.J.