Re: optimal encoding of SIMD insns

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

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:
>>>>>>>>>> On 20.11.17 at 14:22, <hjl.tools@gmail.com> wrote:
>>>>>>>> We can add one mapped to {vex2}, {vex3}, {evex} directives.
>>>>>>>
>>>>>>> I'm afraid I don't understand what you're trying to suggest, or
>>>>>>> how that is related to the original question.
>>>>>>>
>>>>>>
>>>>>> Yes, we can add a command option as well as .vex2/.vex3/.evex
>>>>>> directives.
>>>>>
>>>>> Oh, you mean to have a way to effect e.g. {vex2} globally? How
>>>>> would that work for things where the pseudo prefix would cause
>>>>> an error because a given insn isn't representable?
>>>>
>>>> It can be used to cancel vex3 command-line option.
>>>
>>> Which still goes against my argument of specifically not wanting
>>> anyone to have to deal with individual insns here. I want a way
>>> to improve encoding _without_ incurring any diagnostics that
>>> then require changes to the original code.
>>
>> Why should the new command line options incur such changes
>> in input?
>
> Isn't it the case that e.g. {vex2} specified on an insn which can
> only be 3-byte VEX encoded results in an error (or at least a
> warning)? If so, that's why a respective command line option or
> directive wouldn't be suitable here. If not, that's a mistake imo.

There is

  * '{vex2}' - prefer 2-byte VEX prefix for VEX instruction.

It shouldn't complain when 2-byte prefix isn't possible.

> (Btw, is {vex2} actually meaningful? I.e. are there cases where
> the assembler would choose another [longer] encoding without
> that pseudo-prefix?)

When there is a command-line option :-).

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

-- 
H.J.