* [Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
@ 2020-04-16 7:02 ` krebbel at gcc dot gnu.org
2020-04-16 7:05 ` krebbel at gcc dot gnu.org
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: krebbel at gcc dot gnu.org @ 2020-04-16 7:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Andreas Krebbel <krebbel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Priority|P3 |P1
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
2020-04-16 7:02 ` [Bug rtl-optimization/94613] " krebbel at gcc dot gnu.org
@ 2020-04-16 7:05 ` krebbel at gcc dot gnu.org
2020-04-16 7:05 ` krebbel at gcc dot gnu.org
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: krebbel at gcc dot gnu.org @ 2020-04-16 7:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #1 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
If we have to assume that we already applied simplifications on the THEN or
ELSE branches it doesn't appear to be correct to look for split points inside
an IF_THEN_ELSE expression anymore.
This patch fixes the testcase for me:
index cff76cd3303..8f90a354977 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5387,8 +5387,12 @@ find_split_point (rtx *loc, rtx_insn *insn, bool
set_src)
/* Otherwise, select our actions depending on our rtx class. */
switch (GET_RTX_CLASS (code))
{
- case RTX_BITFIELD_OPS: /* This is ZERO_EXTRACT and
SIGN_EXTRACT. */
case RTX_TERNARY:
+ /* Don't split inside then/else branches of an IF_THEN_ELSE.
+ Simplification might have changed the expressions based on
+ the condition. */
+ return 0;
+ case RTX_BITFIELD_OPS: /* This is ZERO_EXTRACT and
SIGN_EXTRACT. */
split = find_split_point (&XEXP (x, 2), insn, false);
if (split)
return split;
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
2020-04-16 7:02 ` [Bug rtl-optimization/94613] " krebbel at gcc dot gnu.org
2020-04-16 7:05 ` krebbel at gcc dot gnu.org
@ 2020-04-16 7:05 ` krebbel at gcc dot gnu.org
2020-04-16 7:09 ` krebbel at gcc dot gnu.org
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: krebbel at gcc dot gnu.org @ 2020-04-16 7:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Andreas Krebbel <krebbel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |10.0
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (2 preceding siblings ...)
2020-04-16 7:05 ` krebbel at gcc dot gnu.org
@ 2020-04-16 7:09 ` krebbel at gcc dot gnu.org
2020-04-16 7:10 ` rguenth at gcc dot gnu.org
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: krebbel at gcc dot gnu.org @ 2020-04-16 7:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #2 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
-fno-ipa-sra is required to get the same results as in the first comment. The
full command line then is:
c1plus -O3 -march=z14 t.ii -quiet -o t.s -fno-ipa-sra
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (3 preceding siblings ...)
2020-04-16 7:09 ` krebbel at gcc dot gnu.org
@ 2020-04-16 7:10 ` rguenth at gcc dot gnu.org
2020-04-16 7:15 ` rguenth at gcc dot gnu.org
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-04-16 7:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Why is it not correct to split the insn the way you describe? I see nothing
wrong with that - the use of r115 is still under r110 == 0. Is the issue
that r115 is re-used and r115 has more than a single use?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (4 preceding siblings ...)
2020-04-16 7:10 ` rguenth at gcc dot gnu.org
@ 2020-04-16 7:15 ` rguenth at gcc dot gnu.org
2020-04-16 7:37 ` krebbel at gcc dot gnu.org
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-04-16 7:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
You might be able to turn this into a RTL testcase with a C driver to make it
suitable for a dg-do run testcase. There's a combine testcase at
gcc.dg/rtl/aarch64/asr_div1.c you could look at (just not dg-do run)
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (5 preceding siblings ...)
2020-04-16 7:15 ` rguenth at gcc dot gnu.org
@ 2020-04-16 7:37 ` krebbel at gcc dot gnu.org
2020-04-16 8:21 ` [Bug target/94613] Wrong code generated for vec_sel builtin krebbel at gcc dot gnu.org
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: krebbel at gcc dot gnu.org @ 2020-04-16 7:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #5 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> Why is it not correct to split the insn the way you describe? I see nothing
> wrong with that - the use of r115 is still under r110 == 0. Is the issue
> that r115 is re-used and r115 has more than a single use?
Yes that's what it appeared to me in the original testcase but I have just
noticed that auto-reduction broke it. In the reduced testcase r115 dies in
INSN 36 so it isn't useful right now. I agree that the splitting is legal in
that case.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (6 preceding siblings ...)
2020-04-16 7:37 ` krebbel at gcc dot gnu.org
@ 2020-04-16 8:21 ` krebbel at gcc dot gnu.org
2020-04-16 8:28 ` [Bug target/94613] S/390: " krebbel at gcc dot gnu.org
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: krebbel at gcc dot gnu.org @ 2020-04-16 8:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Andreas Krebbel <krebbel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P1 |P2
Summary|combine: Wrong code due to |Wrong code generated for
|splitting a simplified |vec_sel builtin
|IF_THEN_ELSE |
Component|rtl-optimization |target
Severity|critical |normal
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (7 preceding siblings ...)
2020-04-16 8:21 ` [Bug target/94613] Wrong code generated for vec_sel builtin krebbel at gcc dot gnu.org
@ 2020-04-16 8:28 ` krebbel at gcc dot gnu.org
2020-04-16 21:18 ` segher at gcc dot gnu.org
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: krebbel at gcc dot gnu.org @ 2020-04-16 8:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Andreas Krebbel <krebbel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P3
Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot gnu.org
--- Comment #6 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
My debugging went into the wrong direction. The problem arises from wrong RTL
being generated in the backend for the vec_sel builtin.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (8 preceding siblings ...)
2020-04-16 8:28 ` [Bug target/94613] S/390: " krebbel at gcc dot gnu.org
@ 2020-04-16 21:18 ` segher at gcc dot gnu.org
2020-04-20 17:39 ` [Bug target/94613] S/390, powerpc: " cvs-commit at gcc dot gnu.org
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: segher at gcc dot gnu.org @ 2020-04-16 21:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|s390x |s390x powerpc*-*-*
Last reconfirmed| |2020-04-16
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Yes. The rs6000 code is bad as well:
(define_insn "*altivec_vsel<mode>"
[(set (match_operand:VM 0 "altivec_register_operand" "=v")
(if_then_else:VM
(ne:CC (match_operand:VM 1 "altivec_register_operand" "v")
(match_operand:VM 4 "zero_constant" ""))
(match_operand:VM 2 "altivec_register_operand" "v")
(match_operand:VM 3 "altivec_register_operand" "v")))]
"VECTOR_MEM_ALTIVEC_P (<MODE>mode)"
"vsel %0,%3,%2,%1"
[(set_attr "type" "vecmove")])
That is not what the insn does (the compare should be *bitwise*: it does
op0 := (op2 & ~op1) | (op3 & op1)
This can be written a few different ways in RTL; we'll have to find out
what works best.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (9 preceding siblings ...)
2020-04-16 21:18 ` segher at gcc dot gnu.org
@ 2020-04-20 17:39 ` cvs-commit at gcc dot gnu.org
2020-05-04 8:39 ` cvs-commit at gcc dot gnu.org
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-20 17:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andreas Krebbel <krebbel@gcc.gnu.org>:
https://gcc.gnu.org/g:2930bb321794c241d8df5591a5bf447bf89c6e82
commit r10-7827-g2930bb321794c241d8df5591a5bf447bf89c6e82
Author: Andreas Krebbel <krebbel@linux.ibm.com>
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 <krebbel@linux.ibm.com>
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<V_HW"): ... this and rewrite the pattern with bitops.
gcc/testsuite/ChangeLog:
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
PR target/94613
* gcc.target/s390/zvector/pr94613.c: New test.
* gcc.target/s390/zvector/vec_sel-1.c: New test.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (10 preceding siblings ...)
2020-04-20 17:39 ` [Bug target/94613] S/390, powerpc: " cvs-commit at gcc dot gnu.org
@ 2020-05-04 8:39 ` cvs-commit at gcc dot gnu.org
2020-05-04 8:43 ` cvs-commit at gcc dot gnu.org
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-05-04 8:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Andreas Krebbel
<krebbel@gcc.gnu.org>:
https://gcc.gnu.org/g:92ee7d437a98a0f9e63549b4aa83af87382821cf
commit r9-8562-g92ee7d437a98a0f9e63549b4aa83af87382821cf
Author: Andreas Krebbel <krebbel@linux.ibm.com>
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 <krebbel@linux.ibm.com>
Backport from mainline
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
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<V_HW"): ... this and rewrite the pattern with bitops.
gcc/testsuite/ChangeLog:
2020-05-04 Andreas Krebbel <krebbel@linux.ibm.com>
Backport from mainline
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
PR target/94613
* gcc.target/s390/zvector/pr94613.c: New test.
* gcc.target/s390/zvector/vec_sel-1.c: New test.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (11 preceding siblings ...)
2020-05-04 8:39 ` cvs-commit at gcc dot gnu.org
@ 2020-05-04 8:43 ` cvs-commit at gcc dot gnu.org
2020-05-07 11:56 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-05-04 8:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Andreas Krebbel
<krebbel@gcc.gnu.org>:
https://gcc.gnu.org/g:cf16ecdd897a73a1651aba50533c5a6fd73e842c
commit r8-10232-gcf16ecdd897a73a1651aba50533c5a6fd73e842c
Author: Andreas Krebbel <krebbel@linux.ibm.com>
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 <krebbel@linux.ibm.com>
Backport from mainline
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
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<V_HW"): ... this and rewrite the pattern with bitops.
gcc/testsuite/ChangeLog:
2020-05-04 Andreas Krebbel <krebbel@linux.ibm.com>
Backport from mainline
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
PR target/94613
* gcc.target/s390/zvector/pr94613.c: New test.
* gcc.target/s390/zvector/vec_sel-1.c: New test.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (12 preceding siblings ...)
2020-05-04 8:43 ` cvs-commit at gcc dot gnu.org
@ 2020-05-07 11:56 ` jakub at gcc dot gnu.org
2020-07-23 6:52 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-05-07 11:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.0 |10.2
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.1 has been released.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (13 preceding siblings ...)
2020-05-07 11:56 ` jakub at gcc dot gnu.org
@ 2020-07-23 6:52 ` rguenth at gcc dot gnu.org
2021-04-08 12:02 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-07-23 6:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.2 |10.3
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.2 is released, adjusting target milestone.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (14 preceding siblings ...)
2020-07-23 6:52 ` rguenth at gcc dot gnu.org
@ 2021-04-08 12:02 ` rguenth at gcc dot gnu.org
2021-05-04 12:32 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-08 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.3 |10.4
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (15 preceding siblings ...)
2021-04-08 12:02 ` rguenth at gcc dot gnu.org
@ 2021-05-04 12:32 ` rguenth at gcc dot gnu.org
2021-05-27 0:57 ` luoxhu at gcc dot gnu.org
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-04 12:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (16 preceding siblings ...)
2021-05-04 12:32 ` rguenth at gcc dot gnu.org
@ 2021-05-27 0:57 ` luoxhu at gcc dot gnu.org
2021-10-28 3:18 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: luoxhu at gcc dot gnu.org @ 2021-05-27 0:57 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (17 preceding siblings ...)
2021-05-27 0:57 ` luoxhu at gcc dot gnu.org
@ 2021-10-28 3:18 ` cvs-commit at gcc dot gnu.org
2021-10-28 3:18 ` cvs-commit at gcc dot gnu.org
2021-10-28 6:04 ` luoxhu at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-10-28 3:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Xiong Hu Luo <luoxhu@gcc.gnu.org>:
https://gcc.gnu.org/g:9222481ffc69a6c0b73ec81e1bf04289fa3db0ed
commit r12-4757-g9222481ffc69a6c0b73ec81e1bf04289fa3db0ed
Author: Xionghu Luo <luoxhu@linux.ibm.com>
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 <luoxhu@linux.ibm.com>
PR target/94613
* config/rs6000/altivec.md (*altivec_vsel<mode>): Change to ...
(altivec_vsel<mode>): ... this and update define.
(*altivec_vsel<mode>_uns): Delete.
(altivec_vsel<mode>2): New define_insn.
(altivec_vsel<mode>3): Likewise.
(altivec_vsel<mode>4): 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<mode>): Change to ...
(vsx_xxsel<mode>): ... this and update define.
(*vsx_xxsel<mode>_uns): Delete.
(vsx_xxsel<mode>2): New define_insn.
(vsx_xxsel<mode>3): Likewise.
(vsx_xxsel<mode>4): Likewise.
gcc/testsuite/ChangeLog:
2021-10-28 Xionghu Luo <luoxhu@linux.ibm.com>
PR target/94613
* gcc.target/powerpc/pr94613.c: New test.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (18 preceding siblings ...)
2021-10-28 3:18 ` cvs-commit at gcc dot gnu.org
@ 2021-10-28 3:18 ` cvs-commit at gcc dot gnu.org
2021-10-28 6:04 ` luoxhu at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-10-28 3:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Xiong Hu Luo <luoxhu@gcc.gnu.org>:
https://gcc.gnu.org/g:5f9ef1339e9d0d709af6a70b60e584bf7decd761
commit r12-4758-g5f9ef1339e9d0d709af6a70b60e584bf7decd761
Author: Xionghu Luo <luoxhu@linux.ibm.com>
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 <luoxhu@linux.ibm.com>
PR target/94613
* config/rs6000/altivec.md: Add vsx register constraints.
* config/rs6000/vsx.md (vsx_xxsel<mode>): Delete.
(vsx_xxsel<mode>2): Likewise.
(vsx_xxsel<mode>3): Likewise.
(vsx_xxsel<mode>4): Likewise.
gcc/testsuite/ChangeLog:
2021-10-28 Xionghu Luo <luoxhu@linux.ibm.com>
* gcc.target/powerpc/builtins-1.c: Adjust.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
2020-04-16 7:01 [Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE krebbel at gcc dot gnu.org
` (19 preceding siblings ...)
2021-10-28 3:18 ` cvs-commit at gcc dot gnu.org
@ 2021-10-28 6:04 ` luoxhu at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: luoxhu at gcc dot gnu.org @ 2021-10-28 6:04 UTC (permalink / raw)
To: 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.
^ permalink raw reply [flat|nested] 22+ messages in thread