[PATCH] x86: Mark cvtpi2ps and cvtpi2pd as MMX

[H.J. Lu]

On Wed, Feb 19, 2020 at 5:40 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 19.02.2020 14:14, H.J. Lu wrote:
> > On Wed, Feb 19, 2020 at 5:04 AM Jan Beulich <jbeulich@suse.com> wrote:
> >> On 19.02.2020 13:58, H.J. Lu wrote:
> >>> --- a/gas/config/tc-i386.c
> >>> +++ b/gas/config/tc-i386.c
> >>> @@ -8636,7 +8636,9 @@ output_insn (void)
> >>>       x86_feature_2_used |= GNU_PROPERTY_X86_FEATURE_2_X87;
> >>>        if (i.has_regmmx
> >>>         || i.tm.base_opcode == 0xf77 /* emms */
> >>> -       || i.tm.base_opcode == 0xf0e /* femms */)
> >>> +       || i.tm.base_opcode == 0xf0e /* femms */
> >>> +       || i.tm.base_opcode == 0xf2a /* cvtpi2ps */
> >>> +       || i.tm.base_opcode == 0x660f2a /* cvtpi2pd */)
> >>
> >> While for the former I agree, the latter - as pointed out
> >> elsewhere - does explicitly _not_ switch into MMX mode when
> >> the source operand is in memory.
> >
> > They are still MMX instructions even with memory operand.
>
> Not exactly, see CVTPI2PD's description in the SDM.

They are MMX in term of pure SSE.

> >>> --- a/gas/testsuite/gas/i386/i386.exp
> >>> +++ b/gas/testsuite/gas/i386/i386.exp
> >>> @@ -601,6 +601,7 @@ if [expr ([istarget "i*86-*-*"] ||  [istarget "x86_64-*-*"]) && [gas_32_check]]
> >>>       run_dump_test "evex-no-scale-32"
> >>>       run_dump_test "property-1"
> >>>       run_dump_test "property-2"
> >>> +     run_dump_test "property-3"
> >>>
> >>>       if {[istarget "*-*-linux*"]} then {
> >>>           run_dump_test "align-branch-3"
> >>> @@ -1166,6 +1167,7 @@ if [expr ([istarget "i*86-*-*"] || [istarget "x86_64-*-*"]) && [gas_64_check]] t
> >>>       run_dump_test "evex-no-scale-64"
> >>>       run_dump_test "x86-64-property-1"
> >>>       run_dump_test "x86-64-property-2"
> >>> +     run_dump_test "x86-64-property-3"
> >>
> >> While I appreciate you adding a test for this case, my
> >> questions from several weeks back on the _intended_ behavior
> >> of this tracking were because I found all of the to be
> >> pretty broken. The brokenness would have become obvious (I
> >> think) if proper testing of at least a fair part of cases
> >> was actually done. Therefore I'm not convinced adding tests
> >> of individual sub-sub-cases is actually going to be helpful.
> >
> > More tests are welcome.
>
> Of course, but before adding tests I'd like to get things into
> sane state, which is going to take time. I'm _not_ going to add
> tests documenting the current, broken state. That's why I did
> ask what the _intended_ behavior actually is (and to be honest
> I'm still left guessing or taking my own decisions, as your
> replies were only partly helpful; hence my shifting it down my
> todo list).
>
> Jan



-- 
H.J.