On Mon, Feb 11, 2019 at 3:32 PM H.J. Lu <hjl.to...@gmail.com> wrote:
>
> On Mon, Feb 11, 2019 at 5:51 AM Uros Bizjak <ubiz...@gmail.com> wrote:
> >
> > On Mon, Feb 11, 2019 at 2:29 PM H.J. Lu <hjl.to...@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.
Uros.
