In Mon, Feb 11, 2019 at 7:56 AM Uros Bizjak <ubiz...@gmail.com> wrote: > > 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.
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.