[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2021-10-27 Thread luoxhu at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from luoxhu at gcc dot gnu.org ---
Fixed on master.

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2021-10-27 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

https://gcc.gnu.org/g:5f9ef1339e9d0d709af6a70b60e584bf7decd761

commit r12-4758-g5f9ef1339e9d0d709af6a70b60e584bf7decd761
Author: Xionghu Luo 
Date:   Wed Oct 27 21:22:39 2021 -0500

rs6000: Fold xxsel to vsel since they have same semantics

Fold xxsel to vsel like xxperm/vperm to avoid duplicate code.

gcc/ChangeLog:

2021-10-28  Xionghu Luo  

PR target/94613
* config/rs6000/altivec.md: Add vsx register constraints.
* config/rs6000/vsx.md (vsx_xxsel): Delete.
(vsx_xxsel2): Likewise.
(vsx_xxsel3): Likewise.
(vsx_xxsel4): Likewise.

gcc/testsuite/ChangeLog:

2021-10-28  Xionghu Luo  

* gcc.target/powerpc/builtins-1.c: Adjust.

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2021-10-27 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

https://gcc.gnu.org/g:9222481ffc69a6c0b73ec81e1bf04289fa3db0ed

commit r12-4757-g9222481ffc69a6c0b73ec81e1bf04289fa3db0ed
Author: Xionghu Luo 
Date:   Wed Oct 27 21:21:20 2021 -0500

rs6000: Fix wrong code generation for vec_sel [PR94613]

The vsel instruction is a bit-wise select instruction.  Using an
IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code
being generated in the combine pass.  Per element selection is a
subset of per bit-wise selection,with the patch the pattern is
written using bit operations.  But there are 8 different patterns
to define "op0 := (op1 & ~op3) | (op2 & op3)":

(~op3&op1) | (op3&op2),
(~op3&op1) | (op2&op3),
(op3&op2) | (~op3&op1),
(op2&op3) | (~op3&op1),
(op1&~op3) | (op3&op2),
(op1&~op3) | (op2&op3),
(op3&op2) | (op1&~op3),
(op2&op3) | (op1&~op3),

The latter 4 cases does not follow canonicalisation rules, non-canonical
RTL is invalid RTL in vregs pass.  Secondly, combine pass will swap
(op1&~op3) to (~op3&op1) by commutative canonical, which could reduce
it to the FIRST 4 patterns, but it won't swap (op2&op3) | (~op3&op1) to
(~op3&op1) | (op2&op3), so this patch handles it with 4 patterns with
different NOT op3 position and check equality inside it.

Tested pass on P7, P8 and P9.

gcc/ChangeLog:

2021-10-28  Xionghu Luo  

PR target/94613
* config/rs6000/altivec.md (*altivec_vsel): Change to ...
(altivec_vsel): ... this and update define.
(*altivec_vsel_uns): Delete.
(altivec_vsel2): New define_insn.
(altivec_vsel3): Likewise.
(altivec_vsel4): Likewise.
* config/rs6000/rs6000-call.c (altivec_expand_vec_sel_builtin):
New.
(altivec_expand_builtin): Call altivec_expand_vec_sel_builtin to
expand
vel_sel.
* config/rs6000/rs6000.c (rs6000_emit_vector_cond_expr): Use
bit-wise
selection instead of per element.
* config/rs6000/vector.md:
* config/rs6000/vsx.md (*vsx_xxsel): Change to ...
(vsx_xxsel): ... this and update define.
(*vsx_xxsel_uns): Delete.
(vsx_xxsel2): New define_insn.
(vsx_xxsel3): Likewise.
(vsx_xxsel4): Likewise.

gcc/testsuite/ChangeLog:

2021-10-28  Xionghu Luo  

PR target/94613
* gcc.target/powerpc/pr94613.c: New test.

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2021-05-26 Thread luoxhu at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org

--- Comment #14 from luoxhu at gcc dot gnu.org ---
Patch submmited:

https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569255.html

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2021-05-04 Thread rguenth at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2021-04-08 Thread rguenth at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|10.3|10.4

--- Comment #13 from Richard Biener  ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2020-07-22 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|10.2|10.3

--- Comment #12 from Richard Biener  ---
GCC 10.2 is released, adjusting target milestone.

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2020-05-07 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.0|10.2

--- Comment #11 from Jakub Jelinek  ---
GCC 10.1 has been released.

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2020-05-04 Thread cvs-commit at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

--- Comment #10 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Andreas Krebbel
:

https://gcc.gnu.org/g:cf16ecdd897a73a1651aba50533c5a6fd73e842c

commit r8-10232-gcf16ecdd897a73a1651aba50533c5a6fd73e842c
Author: Andreas Krebbel 
Date:   Mon May 4 10:43:02 2020 +0200

PR94613: Fix vec_sel builtin for IBM Z

The vsel instruction is a bit-wise select instruction.  Using an
IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code being
generated in the combine pass.

With the patch the pattern is written using bit operations.  However,
I've just noticed that the manual still demands a fixed point mode for
AND/IOR and friends although several targets emit bit ops on floating
point vectors (including i386, Power, and s390). So I assume this is a
safe thing to do?!

gcc/ChangeLog:

2020-05-04  Andreas Krebbel  

Backport from mainline
2020-04-20  Andreas Krebbel  

PR target/94613
* config/s390/s390-builtin-types.def: Add 3 new function modes.
* config/s390/s390-builtins.def: Add mode dependent low-level
builtin and map the overloaded builtins to these.
* config/s390/vx-builtins.md ("vec_selV_HW"): Rename to ...
("vsel

Backport from mainline
2020-04-20  Andreas Krebbel  

PR target/94613
* gcc.target/s390/zvector/pr94613.c: New test.
* gcc.target/s390/zvector/vec_sel-1.c: New test.

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2020-05-04 Thread cvs-commit at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Andreas Krebbel
:

https://gcc.gnu.org/g:92ee7d437a98a0f9e63549b4aa83af87382821cf

commit r9-8562-g92ee7d437a98a0f9e63549b4aa83af87382821cf
Author: Andreas Krebbel 
Date:   Mon Apr 20 19:36:33 2020 +0200

PR94613: Fix vec_sel builtin for IBM Z

The vsel instruction is a bit-wise select instruction.  Using an
IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code being
generated in the combine pass.

With the patch the pattern is written using bit operations.  However,
I've just noticed that the manual still demands a fixed point mode for
AND/IOR and friends although several targets emit bit ops on floating
point vectors (including i386, Power, and s390). So I assume this is a
safe thing to do?!

gcc/ChangeLog:

2020-05-04  Andreas Krebbel  

Backport from mainline
2020-04-20  Andreas Krebbel  

PR target/94613
* config/s390/s390-builtin-types.def: Add 3 new function modes.
* config/s390/s390-builtins.def: Add mode dependent low-level
builtin and map the overloaded builtins to these.
* config/s390/vx-builtins.md ("vec_selV_HW"): Rename to ...
("vsel

Backport from mainline
2020-04-20  Andreas Krebbel  

PR target/94613
* gcc.target/s390/zvector/pr94613.c: New test.
* gcc.target/s390/zvector/vec_sel-1.c: New test.

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

2020-04-20 Thread cvs-commit at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Andreas Krebbel :

https://gcc.gnu.org/g:2930bb321794c241d8df5591a5bf447bf89c6e82

commit r10-7827-g2930bb321794c241d8df5591a5bf447bf89c6e82
Author: Andreas Krebbel 
Date:   Mon Apr 20 19:36:33 2020 +0200

PR94613: Fix vec_sel builtin for IBM Z

The vsel instruction is a bit-wise select instruction.  Using an
IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code being
generated in the combine pass.

With the patch the pattern is written using bit operations.  However,
I've just noticed that the manual still demands a fixed point mode for
AND/IOR and friends although several targets emit bit ops on floating
point vectors (including i386, Power, and s390). So I assume this is a
safe thing to do?!

gcc/ChangeLog:

2020-04-20  Andreas Krebbel  

PR target/94613
* config/s390/s390-builtin-types.def: Add 3 new function modes.
* config/s390/s390-builtins.def: Add mode dependent low-level
builtin and map the overloaded builtins to these.
* config/s390/vx-builtins.md ("vec_selV_HW"): Rename to ...
("vsel

PR target/94613
* gcc.target/s390/zvector/pr94613.c: New test.
* gcc.target/s390/zvector/vec_sel-1.c: New test.