Re: [PATCH 2/5] x86: improve SIMD to‑scalar‑int conversion insn handling

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

On Thu, Mar 22, 2018 at 5:06 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 22.03.18 at 12:54, <hjl.tools@gmail.com> wrote:
>> On Thu, Mar 22, 2018 at 4:42 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 22.03.18 at 12:23, <hjl.tools@gmail.com> wrote:
>>>> On Thu, Mar 22, 2018 at 12:42 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 21.03.18 at 20:17, <hjl.tools@gmail.com> wrote:
>>>>>> On Wed, Mar 21, 2018 at 7:20 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> In the course of folding their patterns (possible now that the pointless
>>>>>>> and partly even bogus VecESize are no longer in the way) I've noticed
>>>>>>> that vcvt*2usi, other than their vcvt*2si counterparts, didn't allow for
>>>>>>> any suffixes. As with all insns touching GPRs, these should be permitted
>>>>>>> even if they're not required for determining operand sizes. In turn I've
>>>>>>> noticed that only a very limited set of cases had a suffix added in
>>>>>>> disassembly with -Msuffix, while all suffixes should be output in that
>>>>>>> mode.
>>>>>>>
>>>>>>> gas/
>>>>>>> 2018-03-21  Jan Beulich  <jbeulich@suse.com>
>>>>>>>
>>>>>>>         * testsuite/gas/i386/cvt-2si.d, testsuite/gas/i386/cvt-2si.s:
>>>>>>>         New.
>>>>>>>         * testsuite/gas/i386/i386.exp: Run new test.
>>>>>>>         * testsuite/gas/i386/ilp32/x86-64-simd-suffix.d,
>>>>>>>         testsuite/gas/i386/simd-suffix.d,
>>>>>>>         testsuite/gas/i386/x86-64-simd-suffix.d: Adjust expectations.
>>>>>>>
>>>>>>> opcodes/
>>>>>>> 2018-03-21  Jan Beulich  <jbeulich@suse.com>
>>>>>>>
>>>>>>>         * i386-dis.c (prefix_table): Replace Y by S for cvt*2si.
>>>>>>>         (vex_len_table): Replace Y by S for vcvt*2si.
>>>>>>>         (putop): Replace plain 'Y' handling by abort().
>>>>>>>         * i386-dis-evex.h (evex_table): Replace Y by S for vcvt*2si.
>>>>>>>         * i386-opc.tbl (vcvt*d2si): Fold AVX512 forms. Add ToDword.
>>>>>>>         (vcvt*s2si): Fold AVX512 forms. Add ToQword.
>>>>>>>         * i386-tlb.h: Re-generate.
>>>>>>
>>>>>> I prefer not to add suffixes to vector instructions with GPRs unless it
>>>>>> is required.
>>>>>
>>>>> I'm afraid I don't follow - suffixes (in particular in suffix-always
>>>>> mode) aren't an optional thing. I actually consider it a mistake
>>>>> for the compiler to omit them, and the compiler _has to_ omit
>>>>> them right now because we don't accept them. Furthermore -
>>>>> did you look at the state things are currently in? If you didn't
>>>>> want suffixes when not needed, why is there the Y format in
>>>>> the first place? And why said inconsistency between 2usi and
>>>>> 2si conversions in the assembler? And more fundamentally -
>>>>> why are vector insns different from others touching GPRs?
>>>>
>>>> I'd to keep AT&T mnemonic as close to SDM as possible.
>>>> There are not much we can do about integer instructions.
>>>> But we should do our best for vector instructions.   There
>>>> are some exceptions as you have noticed.   A suffix is needed
>>>> for some vector instructions to tell size.
>>>
>>> Again - I think consistency is more important here. It would
>>> anyway help if you answered the individual questions I've
>>> raised above, not just the last one.
>>>
>>> As to the effect on gcc: I'm quite certain that a bug they have
>>> (and which I have a fix for, just that it's not the right time to
>>> submit it, as the tree is basically frozen) is a more or less direct
>>> result of the (enforced) lack of suffix on the 2usi conversions
>>> here: They mis-compile usi2 conversions from 64-bit integers,
>>> due to omitting the suffix from the generated assembly.
>>
>> Is there a GCC bug for it?
>
> No, I intend to simply send the patch once the tree re-opens.
>
>>> Just like for Intel syntax they always output the operand size,
>>> for AT&T syntax they should always output a suffix if one can
>>> sensibly be applied. This helps verifying that things are actually
>>> consistent. But of course the assembler has to allow for it.
>>
>> What I prefer is I can look up an instruction by name in SDM.
>> For integer instructions, they are tricky since some instructions
>> have suffixes and some have different names.   I'd like to avoid
>> suffixes for vector instructions as much as possible.  If we can
>> uniquely encode a vector instruction with suffix, we shouldn't add
>> one.
>
> I understand that's one possible goal, but that ship has long sailed
> (unless you want to _remove_ support for certain suffixes). Sadly
> you still didn't say anything on the inconsistent state things are in
> right now. See the questions raised earlier.
>

If we exclude integer instructions from this discussion, vector
instructions are quite consistent without suffix.   Yes, some vector
instructions do need suffixes, but only a few.

-- 
H.J.