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

["Jan Beulich" <JBeulich at suse dot com>]

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

Jan