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

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

On Fri, Dec 15, 2017 at 8:36 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>> "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.
>

Patch is OK then.

Thanks.

-- 
H.J.