[Bug target/91117] _mm_movpi64_epi64/_mm_movepi64_pi64 generating store+load instead of using MOVQ2DQ/MOVDQ2Q

2020-01-27 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91117 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/91117] _mm_movpi64_epi64/_mm_movepi64_pi64 generating store+load instead of using MOVQ2DQ/MOVDQ2Q

2019-07-09 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91117 --- Comment #3 from Uroš Bizjak --- (In reply to Wolf . from comment #2) > Is there any way to still access MMX instructions/registers with intrinsics > in gcc-10 at all or is this bug "fixable but that code generation option > will go away

[Bug target/91117] _mm_movpi64_epi64/_mm_movepi64_pi64 generating store+load instead of using MOVQ2DQ/MOVDQ2Q

2019-07-09 Thread wolfwings+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91117 --- Comment #2 from Wolf . --- Is there any way to still access MMX instructions/registers with intrinsics in gcc-10 at all or is this bug "fixable but that code generation option will go away entirely with gcc-10 so it wouldn't matter" then?

[Bug target/91117] _mm_movpi64_epi64/_mm_movepi64_pi64 generating store+load instead of using MOVQ2DQ/MOVDQ2Q

2019-07-09 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91117 --- Comment #1 from Uroš Bizjak --- The generated code is created the way it is partially by design, and partially by missing (!y,*x) alternative in *vec_extractv2di_0_sse. GCC lowers intrinsics to generic operations, and this has its pluses