Re: optimal encoding of SIMD insns

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

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

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

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

Jan