[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[kl4yfd at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

kl4yfd at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kl4yfd at gmail dot com

--- Comment #3 from kl4yfd at gmail dot com 2012-11-15 06:36:17 UTC ---
Additional way to cause this bug discovered.

By using global mmX register variables, reads & writes to/from these locations
incur mmX operands automatically.

Even when compiled _without_ -mmmx flag, these MMX operands are generated by
gcc!

As the bug name states, no emms opcode is generated to leave MMX state/mode and
return the FPU to working order. 


  1) why does gcc _not_ place the emms opcode at the end of all binaries
compiled with -mmmx for safety-sake?
  2) Why does gcc generate MMX opcodes even without the -mmmx compile flag?

-------------------

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[kl4yfd at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

--- Comment #4 from kl4yfd at gmail dot com 2012-11-15 06:39:23 UTC ---
Created attachment 28695
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28695
mmX global register no emms

Added example C source file showing the issue mentioned in comment 3

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
      Known to work|                            |

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-15 12:06:34 UTC ---
Using mmX as global registers variables is a user bug if you ever call
something that might be using FPU stack, because the registers can't be
preserved across that.  Don't do that.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[kl4yfd at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

--- Comment #6 from kl4yfd at gmail dot com 2012-11-15 17:05:16 UTC ---
(In reply to comment #5)
> Using mmX as global registers variables is a user bug if you ever call
> something that might be using FPU stack, because the registers can't be
> preserved across that.  Don't do that.

When running x86 in protected mode, you are right. User-error.
This is not for an error within the binary, rather an issue with the processor
state left-over after executable is finished.

For those of us not running in a protected mode / OS environment, ending a
binary execution that calls mmX instructions and does not issue emms leaves the
FPU essentially disabled.

One should never have to manually insert the opcodes 0F 77 into the binary for
proper inter-binary execution in a non-protected mode x86 environment and the
FPU being enabled should be the default assumption.

The example file is only to show that gcc has 3 bugs in its current mmx
handling:

- will auto-generate mmX opcodes, then not auto-generate the emms OP. 
- mmX opcodes were generated without the -mmmx flag.
- when -mmmx flag is used, emms OP is not inserted by default before return.
OK. Why not?
  -- Implementing this would be a great catch-all solution for many problems
associated with drivers, embedded, or the compiler using mmx
OPs/registers/inline-asm then not inserting an emms OP before returning.
  ^^ this will probably require some discussion ^^

If GCC is going to allow neat-features like global register variables, then it
needs to be checked to ensure they are properly used. 

----------------------
- This is part of the fix (mostly real code...) 
- Also a similar check is needed whereever something that generates mmX OPs is
used. (like scoped mmX register variables) etc
- This does not address the fact that no emms is generated. That should be
covered by the catch-all -mmmx flag usage auto-inserts emms opcode @ binary
end.
  -- If that ends up being the solution.

=== From  gcc/varasm.c | line:1209 | gcc 4.7.2 ===

     /* First detect errors in declaring global registers.  */
      if (reg_number == -1)
        error ("register name not specified for %q+D", decl);

/// New PsuedoCode
      else if (MMX_REGNO_P(reg_number) ) {
        if ( !(-mmmx) )
                error ("mmx register usage requires -mmmx flag for %q+D",
decl);
        if ( !(-mfpmath=sse) )
                error ("mmx register usage requires -mfpmath=sse flag for
%q+D", decl);
///
        }
      else if (reg_number < 0)
        error ("invalid register name for %q+D", decl);
      else if (mode == BLKmode)
        error ("data type of %q+D isn%'t suitable for a register",
               decl);

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[tejohnson at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

Teresa Johnson <tejohnson at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tejohnson at google dot com

--- Comment #7 from Teresa Johnson <tejohnson at google dot com> 2013-04-29 16:44:10 UTC ---
*** Update on below text: As of r198401 the problem is hidden unless compiling
with -mtune=athlon64 due to some tuning changes. ***

I have another instance of this issue. Trunk is generating move instructions to
implement an inlined memcpy. The move instructions use the MMX registers, but
no EMMS instruction is generated. My testcase then calls a libm function that
uses the FPU, which returns incorrect results. This worked with an older gcc
4.7 based compiler, which didn't use MMX registers.

The compiler was configured for x86_64-unknown-linux-gnu. The testcase was
compiled with -O2.

$ cat test.cc
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <stdio.h>

namespace {
volatile double dd = 0.080553657784353652;
double dds, ddc;
}

unsigned long long test(float num) {
  if (num < 0) {
    num = 0;
  }

  unsigned int i;
  memcpy(&i, &num, sizeof(unsigned int));
  unsigned long long a = i;

  sincos(dd, &dds, &ddc);
  if (isnan(dds) || isnan(ddc))
  {
    printf ("Failed\n");
    exit (1);
  }
  return a;
}

$ cat test_main.cc
#include <stdio.h>

extern unsigned long long test(float num);
int main()
{
  unsigned long long h = test(1);
  printf ("Passed\n");
}

$ g++ -O2 test*.cc -mtune=athlon64 (See earlier note on why -mtune=athlon64 is
needed here)

$ a.out
Failed

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

--- Comment #8 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-29 17:13:30 UTC ---
Please try following patch, it fixes the testcase for me (note "!" for ?*y
alternative):

--cut here--
Index: i386.md
===================================================================
--- i386.md     (revision 198401)
+++ i386.md     (working copy)
@@ -3049,10 +3049,10 @@

 (define_insn "*zero_extendsidi2"
   [(set (match_operand:DI 0 "nonimmediate_operand"
-                       "=r,?r,?o,r   ,o,?*Ym,?*y,?*Yi,?*x")
+                       "=r,?r,?o,r   ,o,?*Ym,?!*y,?*Yi,?*x")
        (zero_extend:DI
         (match_operand:SI 1 "x86_64_zext_operand"
-                       "0 ,rm,r ,rmWz,0,r   ,m  ,r   ,m")))]
+                       "0 ,rm,r ,rmWz,0,r   ,m   ,r   ,m")))]
   ""
 {
   switch (get_attr_type (insn))
--cut here--

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[tejohnson at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

--- Comment #9 from Teresa Johnson <tejohnson at google dot com> 2013-04-29 17:24:42 UTC ---
It does fix the issue I had in this test case. But theoretically can't
this pattern still generate an MMX reference in some cases? And I see
other instances of the same constraint in i386.md - is there a larger
issue here and how can we prevent this?

Thanks!
Teresa

On Mon, Apr 29, 2013 at 10:13 AM, ubizjak at gmail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578
>
> --- Comment #8 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-29 17:13:30 UTC ---
> Please try following patch, it fixes the testcase for me (note "!" for ?*y
> alternative):
>
> --cut here--
> Index: i386.md
> ===================================================================
> --- i386.md     (revision 198401)
> +++ i386.md     (working copy)
> @@ -3049,10 +3049,10 @@
>
>  (define_insn "*zero_extendsidi2"
>    [(set (match_operand:DI 0 "nonimmediate_operand"
> -                       "=r,?r,?o,r   ,o,?*Ym,?*y,?*Yi,?*x")
> +                       "=r,?r,?o,r   ,o,?*Ym,?!*y,?*Yi,?*x")
>         (zero_extend:DI
>          (match_operand:SI 1 "x86_64_zext_operand"
> -                       "0 ,rm,r ,rmWz,0,r   ,m  ,r   ,m")))]
> +                       "0 ,rm,r ,rmWz,0,r   ,m   ,r   ,m")))]
>    ""
>  {
>    switch (get_attr_type (insn))
> --cut here--
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

--- Comment #10 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-29 17:37:03 UTC ---
(In reply to comment #9)
> It does fix the issue I had in this test case. But theoretically can't
> this pattern still generate an MMX reference in some cases? And I see
> other instances of the same constraint in i386.md - is there a larger
> issue here and how can we prevent this?

Yes, leaks of MMX registers were quite problematic in the past. A lot of effort
went into insn patterns to balance register allocator to allow MMX registers
when necessary, and to avoid them otherwise. It looks that zero_extendsidi
pattern was skipped in these efforts.

-mno-mmx can be used to prevent MMX regs, but the allocator is quite well tuned
nowadays, so instantiation of %mmX registers when not strictly needed will be
considered a bug.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2013-04/msg01756.htm
                   |                            |l
         AssignedTo|unassigned at gcc dot       |ubizjak at gmail dot com
                   |gnu.org                     |
   Target Milestone|---                         |4.7.4

--- Comment #11 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-30 05:38:48 UTC ---
Author: uros
Date: Mon Apr 29 20:16:48 2013
New Revision: 198433

URL: http://gcc.gnu.org/viewcvs?rev=198433&root=gcc&view=rev
Log:
    PR target/44578
    * config/i386/i386.md (*zero_extendsidi2): Add "!" to m->?*y
    alternative.

testsuite/ChangeLog:

    PR target/44578
    * gcc.target/i386/pr44578.c: New test.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr44578.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md
    trunk/gcc/testsuite/ChangeLog

Author: uros
Date: Mon Apr 29 22:16:04 2013
New Revision: 198434

URL: http://gcc.gnu.org/viewcvs?rev=198434&root=gcc&view=rev
Log:
    Backport from mainline
    2013-04-29  Uros Bizjak  <ubizjak@gmail.com>

    PR target/44578
    * config/i386/i386.md (*zero_extendsidi2_rex64): Add "!" to m->?*y
    alternative.
    (*zero_extendsidi2): Ditto.

    Backport from mainline
    2013-04-29  Uros Bizjak  <ubizjak@gmail.com>

    PR target/57098
    * config/i386/i386.c (ix86_expand_vec_perm): Validize constant memory.

testsuite/ChangeLog:

    Backport from mainline
    2013-04-29  Uros Bizjak  <ubizjak@gmail.com>

    PR target/44578
    * gcc.target/i386/pr44578.c: New test.

    Backport from mainline
    2013-04-29  Uros Bizjak  <ubizjak@gmail.com>

    PR target/57098
    * gcc.target/i386/pr57098.c: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr44578.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr57098.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c
    branches/gcc-4_8-branch/gcc/config/i386/i386.md
    branches/gcc-4_8-branch/gcc/config/i386/sse.md
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

Author: uros
Date: Tue Apr 30 05:30:20 2013
New Revision: 198439

URL: http://gcc.gnu.org/viewcvs?rev=198439&root=gcc&view=rev
Log:
    Backport from mainline
    2013-04-29  Uros Bizjak  <ubizjak@gmail.com>

    PR target/44578
    * config/i386/i386.md (*zero_extendsidi2_rex64): Add "!" to m->?*y
    alternative.
    (*zero_extendsidi2): Ditto.

    Backport from mainline
    2013-04-29  Uros Bizjak  <ubizjak@gmail.com>

    PR target/57098
    * config/i386/i386.c (ix86_expand_vec_perm): Validize constant memory.

testsuite/ChangeLog:

    Backport from mainline
    2013-04-29  Uros Bizjak  <ubizjak@gmail.com>

    PR target/44578
    * gcc.target/i386/pr44578.c: New test.

    Backport from mainline
    2013-04-29  Uros Bizjak  <ubizjak@gmail.com>

    PR target/57098
    * gcc.target/i386/pr57098.c: New test.


Added:
    branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr44578.c
    branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr57098.c
Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/config/i386/i386.c
    branches/gcc-4_7-branch/gcc/config/i386/i386.md
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[tejohnson at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

--- Comment #12 from Teresa Johnson <tejohnson at google dot com> 2013-04-30 05:43:06 UTC ---
On Mon, Apr 29, 2013 at 10:37 AM, ubizjak at gmail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578
>
> --- Comment #10 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-29 17:37:03 UTC ---
> (In reply to comment #9)
>> It does fix the issue I had in this test case. But theoretically can't
>> this pattern still generate an MMX reference in some cases? And I see
>> other instances of the same constraint in i386.md - is there a larger
>> issue here and how can we prevent this?
>
> Yes, leaks of MMX registers were quite problematic in the past. A lot of effort
> went into insn patterns to balance register allocator to allow MMX registers
> when necessary, and to avoid them otherwise. It looks that zero_extendsidi
> pattern was skipped in these efforts.

Thanks for the quick fix!

>
> -mno-mmx can be used to prevent MMX regs, but the allocator is quite well tuned
> nowadays, so instantiation of %mmX registers when not strictly needed will be
> considered a bug.

I found that due to the header file structure I cannot use -mno-mmx in
certain cases - i.e. when including the STL <algorithm> header file
and compiling with c++11. Is this a known issue/limitation?

(after adding "#include <algorithm>" to the top of my test.cc test case):

$ /usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/bin/g++
-O test.cc -g -S -std=c++11 -mno-mmx
In file included from
/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/xmmintrin.h:35:0,
                 from
/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/x86intrin.h:34,
                 from
/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/include/c++/4.9.0/bits/opt_random.h:33,
                 from
/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/include/c++/4.9.0/random:51,
                 from
/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/include/c++/4.9.0/bits/stl_algo.h:65,
                 from
/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/include/c++/4.9.0/algorithm:62,
                 from test.cc:6:
/usr/local/google/home/tejohnson/gcc_trunk_1_validate/bld-gcc/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/mmintrin.h:31:3:
error: #error "MMX instruction set not enabled"
 # error "MMX instruction set not enabled"
   ^

Thanks,
Teresa

>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.



--
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

--- Comment #13 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-30 05:53:42 UTC ---
(In reply to comment #12)

> I found that due to the header file structure I cannot use -mno-mmx in
> certain cases - i.e. when including the STL <algorithm> header file
> and compiling with c++11. Is this a known issue/limitation?

This is known non-issue; intrinsics require MMX instruction set enabled, this
is the reason why so much effort was put into this problem.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #14 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-30 06:07:17 UTC ---
The original problem was fixed in 4.5.

The issue with global MMX registers (Comment #3) won't be fixed - it is user
error, please see Comment #5 for the explanation. Also, according to MMX ABI,
it is user responsibility to call _mm_empty at the end of MMX intrinsics
sequence to "empty the multimedia state".

The problem from Comment #7 is fixed in 4.7.4, 4.8.1 and 4.9.0.

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[ubizjak at gmail dot com]

------- Comment #2 from ubizjak at gmail dot com  2010-06-19 17:23 -------
Confirmed with 4.4. This is fixed in 4.5, so 4.5 and 4.6 work OK.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.4.5
      Known to work|                            |4.5.0 4.6.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578

[Bug target/44578] GCC generates MMX instructions but fails to generate "emms"

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-18 10:46 -------
As -mfpmath=sse isn't supposed to change the ABI we should never emit MMX
instructions automagically.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2010-06-18 10:46:13
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578