[PATCH] i386: Use EXT_REX_SSE_REG_P in *movoi_internal_avx/movti_internal

[H.J. Lu]

In Mon, Feb 11, 2019 at 7:56 AM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Mon, Feb 11, 2019 at 3:32 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Mon, Feb 11, 2019 at 5:51 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> > >
> > > On Mon, Feb 11, 2019 at 2:29 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > > > No. As said, please correctly set mode to XImode in mode attribute calculation.
> > > >
> > > > There is
> > > >
> > > >  switch (get_attr_type (insn))
> > > >     {
> > > >     case TYPE_SSELOG1:
> > > >       return standard_sse_constant_opcode (insn, operands);
> > > >
> > > > standard_sse_constant_opcode has
> > > >
> > > > else if (x == constm1_rtx || vector_all_ones_operand (x, mode))
> > > >     {
> > > >       enum attr_mode insn_mode = get_attr_mode (insn);
> > > >
> > > >       switch (insn_mode)
> > > >         {
> > > >         case MODE_XI:
> > > >         case MODE_V8DF:
> > > >         case MODE_V16SF:
> > > >           gcc_assert (TARGET_AVX512F);
> > > >           return "vpternlogd\t{$0xFF, %g0, %g0, %g0|%g0, %g0, %g0, 0xFF}";
> > >
> > > If there is something wrong with standard_sse_constant_opcode, then
> > > fix the problem in the function itself. With your previous patch, you
> > > introduced a regression, and the presented fix is another kludge to
> > > fix a stack of kludges inside standard_sse_constant_opcode.
> > >
> > > Please take your time and propose some acceptable solution that would
> > > put some logic into const_0/const_1 handling. The situation is not OK
> > > and your patch makes it even worse.
> > >
> >
> > Let's first define what MODE_XI means in standard_sse_constant_opcode
> > as well as in all these mov patterns for with and without AVX512VL.   Without
> > a clear definition, we can't get out of this mess.
>
> INT_MODE (OI, 32);
> INT_MODE (XI, 64);
>
> So, XI_MODE represents 64 INTEGER bytes = 64 * 8 = 512 bit operation,
> in case of const_1, all 512 bits set.
>
> We can load zeros with narrower instruction, (e.g. 256 bit by inherent
> zeroing of highpart in case of 128 bit xor), so TImode in this case.
>
> Some targets prefer V4SF mode, so they will emit float xorps for zeroing
>
> Then the introduction of AVX512F fubared everything by overloading the
> meaning of insn mode.

Exactly.

How should we use INSN mode,  MODE_XI, in standard_sse_constant_opcode
and patterns which use standard_sse_constant_opcode? 2 options:

1.  MODE_XI should only used to check if EXT_REX_SSE_REG_P is true
in any register operand.  The operand size must be determined by operand
itself , not by MODE_XI.  The operand encoding size should be determined
by the operand size, EXT_REX_SSE_REG_P and AVX512VL.
2. MODE_XI should be used to determine the operand encoding size.
EXT_REX_SSE_REG_P and AVX512VL should be checked for encoding
instructions.

Which way should we go?

-- 
H.J.