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.
--
H.J.
