This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 2/5] x86: improve SIMD to‑scalar‑int conversion insn handling
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?
> 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.
--
H.J.