Re: optimal encoding of SIMD insns

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

On Wed, Nov 22, 2017 at 6:13 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 22.11.17 at 14:47, <hjl.tools@gmail.com> wrote:
>> On Wed, Nov 22, 2017 at 5:11 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 22.11.17 at 13:43, <hjl.tools@gmail.com> wrote:
>>>> On Tue, Nov 21, 2017 at 11:44 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 21.11.17 at 23:14, <hjl.tools@gmail.com> wrote:
>>>>>> On Mon, Nov 20, 2017 at 6:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>>> On 20.11.17 at 14:51, <hjl.tools@gmail.com> wrote:
>>>>>>>> On Mon, Nov 20, 2017 at 5:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> And then - does your reply mean you don't think we could derive
>>>>>>> the encoding selection from the most recent -march/.arch (maybe
>>>>>>> also -mtune) setting?
>>>>>>
>>>>>> No, I don't think so.
>>>>>
>>>>> Please would you mind being a little less terse here: I'd really
>>>>> like to understand the "why" behind your answer.
>>>>
>>>>  -march/.arch shouldn't change encoding.
>>>
>>> I'm sorry to say that, but this still leaves me asking: Why? Aren't
>>> there already cases where they do (for example for shifts with an
>>> immediate of 1 for the i486)? By stating the target architecture
>>> explicitly (rather than running in the default, everything enabled
>>> mode) the user tells us what processor the produced code is
>>> intended to run.
>>
>> This doesn't apply to SSE/VEX/EVEX encoding.  We don't use
>> EVEX encoding to encode AVX instructions just because it is available.
>
> This looks to become a never ending story: You again only state a
> fact, without giving any reason. Why should we not do so if it
> helps improve code density? The more that the original example I
> gave
>
>         vaddps (%rax),xmm0,xmm0
>
> does not in any way state that this is meant to be a VEX-encoded
> insn. It is instead a courtesy of the assembler to use the encoding
> compatible with the widest range of hardware if it selects the VEX
> variant here. -march/.arch are precisely to tell the assembler that
> it doesn't need to consider too old hardware.
>
> And considering the example I gave in my previous reply, where
> would you draw the boundary?

We change VEX/EVEX encoding for -march/-mtune if we can
show there is a performance advantage.


-- 
H.J.