This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 3/4] x86: fold RegXMM/RegYMM/RegZMM into RegSIMD
>>> "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