[PATCH 3/4] x86: fold RegXMM/RegYMM/RegZMM into RegSIMD

[Jan Beulich]

>>> "H.J. Lu" <hjl.tools@gmail.com> 12/15/17 5:28 PM >>>
>On Fri, Dec 15, 2017 at 8:22 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>> "H.J. Lu" <hjl.tools@gmail.com> 12/15/17 1:50 PM >>>
>>>On Fri, Dec 15, 2017 at 2:34 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> @@ -5930,20 +5958,6 @@ finalize_imm (void)
>>>>  }
>>>>
>>>>  static int
>>>> -bad_implicit_operand (int xmm)
>>>> -{
>>>> -  const char *ireg = xmm ? "xmm0" : "ymm0";
>>>> -
>>>> -  if (intel_syntax)
>>>> -    as_bad (_("the last operand of `%s' must be `%s%s'"),
>>>> -           i.tm.name, register_prefix, ireg);
>>>> -  else
>>>> -    as_bad (_("the first operand of `%s' must be `%s%s'"),
>>>> -           i.tm.name, register_prefix, ireg);
>>>> -  return 0;
>>>> -}
>>>> -
>>>
>>>Will we miss the assembly operand error checking?
>>
>> Not sure I understand what you mean. As the altered test case shows, error
>> messages are still present, just that they don't mention %xmm0 anymore. If
>> you mean something else, please explain. But keep in mind that things are
>> now more similar to GPR accumulator (i.e. %al etc) or FPU (%st(0)) handling,
>> where there is no such problem either. The template now requires %xmm0 to
>> be used.
>
>It is hard to tell what the error message is from
>
>*:[0-9]*: Error: .*blendvpd.*
>
>We used to get
>
>The last operand of ....
>
>What do we get now instead?

"operand type mismatch for ..." iirc. I don't think it was appropriate for the
earlier more specific error message to be there in the first place - as said, this
is now and should always have been similar to e.g. FPU insns requiring %st(0)
as one of their operands, where %st(0) isn't being mentioned in the diagnostic
either afair.

Jan