[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||11.4.1 --- Comment #28 from Richard Biener --- Fixed.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #27 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ca4a4cc0060cb8ae1a326d6dbfcd9459452e1574 commit r11-10841-gca4a4cc0060cb8ae1a326d6dbfcd9459452e1574 Author: Jakub Jelinek Date: Sun May 21 13:36:56 2023 +0200 match.pd: Ensure (op CONSTANT_CLASS_P CONSTANT_CLASS_P) is simplified [PR109505] On the following testcase we hang, because POLY_INT_CST is CONSTANT_CLASS_P, but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) simplification actually relies on the (CST1 & CST2) simplification, otherwise it is a deoptimization, trading 2 ops for 3 and furthermore running into /* Given a bit-wise operation CODE applied to ARG0 and ARG1, see if both operands are another bit-wise operation with a common input. If so, distribute the bit operations to save an operation and possibly two if constants are involved. For example, convert (A | B) & (A | C) into A | (B & C) Further simplification will occur if B and C are constants. */ simplification which simplifies that (x & CST2) | (CST1 & CST2) back to CST2 & (x | CST1). I went through all other places I could find where we have a simplification with 2 CONSTANT_CLASS_P operands and perform some operation on those two, while the other spots aren't that severe (just trade 2 operations for another 2 if the two constants don't simplify, rather than as in the above case trading 2 ops for 3), I still think all those spots really intend to optimize only if the 2 constants simplify. So, the following patch adds to those a ! modifier to ensure that, even at GENERIC that modifier means !EXPR_P which is exactly what we want IMHO. 2023-05-21 Jakub Jelinek PR tree-optimization/109505 * match.pd ((x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2), Combine successive equal operations with constants, (A +- CST1) +- CST2 -> A + CST3, (CST1 - A) +- CST2 -> CST3 - A, CST1 - (CST2 - A) -> CST3 + A): Use ! on ops with 2 CONSTANT_CLASS_P operands. * gcc.target/aarch64/sve/pr109505.c: New test. (cherry picked from commit f211757f6fa9515e3fd1a4f66f1a8b48e500c9de)
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #26 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:bfa476528ceeac96865a48c49f3f1a15d566d209 commit r11-10840-gbfa476528ceeac96865a48c49f3f1a15d566d209 Author: Richard Biener Date: Wed Feb 23 13:47:01 2022 +0100 middle-end/109505 - backport match.pd ! support for GENERIC The patch adds support for the ! modifier to GENERIC, backported from r12-7361-gfdc46830f1b793. 2023-06-02 Richard Biener PR tree-optimization/109505 * doc/match-and-simplify.texi: Amend ! documentation. * genmatch.c (expr::gen_transform): Code-generate ! support for GENERIC. (parser::parse_expr): Allow ! for GENERIC.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #25 from Richard Biener --- I'm testing a backport.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #24 from Jakub Jelinek ---
The fix doesn't really work for 11/10:
../../gcc/match.pd:1546:36 error: forcing simplification to a leaf is not
supported for GENERIC
(bit_ior (bit_and @0 @2) (bit_and! @1 @2)))
^
So, we'd either have to guard those patterns with #ifndef GENERIC, but that
would be quite risky change this late on those branches, or perhaps could do
something like
#ifdef GENERIC
(with { tree a = fold_binary (BIT_AND_EXPR, type, @1, @2); }
(if (a && CONSTANT_CLASS_P (a))
(bit_ior (bit_and @0 @2) { a; })))
#else
(bit_ior (bit_and @0 @2) (bit_and! @1 @2)))
#endif
But for all those spots the patch changed. I'm afraid I really don't have time
to do that.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #23 from tt_1 --- Are there any plans to backport this fix to the gcc-11 branch as well? Seems it is affected, if you go by the known to fail list.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #22 from Jakub Jelinek --- Fixed for 12.4, 13.2 and 14.1.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #21 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6ef4e2e11c653f1d51f9a304a8d1cf44a53b4ad7 commit r12-9634-g6ef4e2e11c653f1d51f9a304a8d1cf44a53b4ad7 Author: Jakub Jelinek Date: Sun May 21 13:36:56 2023 +0200 atch.pd: Ensure (op CONSTANT_CLASS_P CONSTANT_CLASS_P) is simplified [PR109505] On the following testcase we hang, because POLY_INT_CST is CONSTANT_CLASS_P, but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) simplification actually relies on the (CST1 & CST2) simplification, otherwise it is a deoptimization, trading 2 ops for 3 and furthermore running into /* Given a bit-wise operation CODE applied to ARG0 and ARG1, see if both operands are another bit-wise operation with a common input. If so, distribute the bit operations to save an operation and possibly two if constants are involved. For example, convert (A | B) & (A | C) into A | (B & C) Further simplification will occur if B and C are constants. */ simplification which simplifies that (x & CST2) | (CST1 & CST2) back to CST2 & (x | CST1). I went through all other places I could find where we have a simplification with 2 CONSTANT_CLASS_P operands and perform some operation on those two, while the other spots aren't that severe (just trade 2 operations for another 2 if the two constants don't simplify, rather than as in the above case trading 2 ops for 3), I still think all those spots really intend to optimize only if the 2 constants simplify. So, the following patch adds to those a ! modifier to ensure that, even at GENERIC that modifier means !EXPR_P which is exactly what we want IMHO. 2023-05-21 Jakub Jelinek PR tree-optimization/109505 * match.pd ((x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2), Combine successive equal operations with constants, (A +- CST1) +- CST2 -> A + CST3, (CST1 - A) +- CST2 -> CST3 - A, CST1 - (CST2 - A) -> CST3 + A): Use ! on ops with 2 CONSTANT_CLASS_P operands. * gcc.target/aarch64/sve/pr109505.c: New test. (cherry picked from commit f211757f6fa9515e3fd1a4f66f1a8b48e500c9de)
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #20 from CVS Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0feece18e6993d02f24a9381ddb5420bb4509554 commit r13-7365-g0feece18e6993d02f24a9381ddb5420bb4509554 Author: Jakub Jelinek Date: Sun May 21 13:36:56 2023 +0200 atch.pd: Ensure (op CONSTANT_CLASS_P CONSTANT_CLASS_P) is simplified [PR109505] On the following testcase we hang, because POLY_INT_CST is CONSTANT_CLASS_P, but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) simplification actually relies on the (CST1 & CST2) simplification, otherwise it is a deoptimization, trading 2 ops for 3 and furthermore running into /* Given a bit-wise operation CODE applied to ARG0 and ARG1, see if both operands are another bit-wise operation with a common input. If so, distribute the bit operations to save an operation and possibly two if constants are involved. For example, convert (A | B) & (A | C) into A | (B & C) Further simplification will occur if B and C are constants. */ simplification which simplifies that (x & CST2) | (CST1 & CST2) back to CST2 & (x | CST1). I went through all other places I could find where we have a simplification with 2 CONSTANT_CLASS_P operands and perform some operation on those two, while the other spots aren't that severe (just trade 2 operations for another 2 if the two constants don't simplify, rather than as in the above case trading 2 ops for 3), I still think all those spots really intend to optimize only if the 2 constants simplify. So, the following patch adds to those a ! modifier to ensure that, even at GENERIC that modifier means !EXPR_P which is exactly what we want IMHO. 2023-05-21 Jakub Jelinek PR tree-optimization/109505 * match.pd ((x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2), Combine successive equal operations with constants, (A +- CST1) +- CST2 -> A + CST3, (CST1 - A) +- CST2 -> CST3 - A, CST1 - (CST2 - A) -> CST3 + A): Use ! on ops with 2 CONSTANT_CLASS_P operands. * gcc.target/aarch64/sve/pr109505.c: New test. (cherry picked from commit f211757f6fa9515e3fd1a4f66f1a8b48e500c9de)
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #19 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f211757f6fa9515e3fd1a4f66f1a8b48e500c9de commit r14-1023-gf211757f6fa9515e3fd1a4f66f1a8b48e500c9de Author: Jakub Jelinek Date: Sun May 21 13:36:56 2023 +0200 atch.pd: Ensure (op CONSTANT_CLASS_P CONSTANT_CLASS_P) is simplified [PR109505] On the following testcase we hang, because POLY_INT_CST is CONSTANT_CLASS_P, but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) simplification actually relies on the (CST1 & CST2) simplification, otherwise it is a deoptimization, trading 2 ops for 3 and furthermore running into /* Given a bit-wise operation CODE applied to ARG0 and ARG1, see if both operands are another bit-wise operation with a common input. If so, distribute the bit operations to save an operation and possibly two if constants are involved. For example, convert (A | B) & (A | C) into A | (B & C) Further simplification will occur if B and C are constants. */ simplification which simplifies that (x & CST2) | (CST1 & CST2) back to CST2 & (x | CST1). I went through all other places I could find where we have a simplification with 2 CONSTANT_CLASS_P operands and perform some operation on those two, while the other spots aren't that severe (just trade 2 operations for another 2 if the two constants don't simplify, rather than as in the above case trading 2 ops for 3), I still think all those spots really intend to optimize only if the 2 constants simplify. So, the following patch adds to those a ! modifier to ensure that, even at GENERIC that modifier means !EXPR_P which is exactly what we want IMHO. 2023-05-21 Jakub Jelinek PR tree-optimization/109505 * match.pd ((x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2), Combine successive equal operations with constants, (A +- CST1) +- CST2 -> A + CST3, (CST1 - A) +- CST2 -> CST3 - A, CST1 - (CST2 - A) -> CST3 + A): Use ! on ops with 2 CONSTANT_CLASS_P operands. * gcc.target/aarch64/sve/pr109505.c: New test.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #18 from Jakub Jelinek --- Created attachment 55124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55124&action=edit gcc14-pr109505.patch I actually think it isn't that bad, we don't have that many, I've looked at match.pd patterns which check for 2 CONSTANT_CLASS_P operands and then try to combine them using some operation and counted just 10 spots which I think need ! added.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #17 from Sam James --- Is there by chance a workaround we can apply for this downstream (some flag)? It prevents building Chromium on arm64 for us w/ gcc unfortunately.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 Andrew Pinski changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #16 from Andrew Pinski --- *** Bug 109794 has been marked as a duplicate of this bug. ***
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #15 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #13)
> (In reply to rsand...@gcc.gnu.org from comment #12)
> > (In reply to Andrew Pinski from comment #11)
> > > For bit_and/bit_ior, VECTOR_CST (I would assume).
> > Ah, yeah. But then I don't think a top-level POLY_INT_CST_P
> > cuts it. We'd have the same problem with VECTOR_CSTs containing
> > POLY_INT_CSTs.
> Do we really support that?
Sure. At least AIUI, VECTOR_CST can contain whatever constants the
associated scalar supports.
A specific example is:
#include
svint32_t f() { return svdup_s32(svcntw()); }
which gives:
return { POLY_INT_CST [4, 4], ... };
https://godbolt.org/z/T1s3n5Pfx
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #14 from rguenther at suse dot de --- On Mon, 17 Apr 2023, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 > > --- Comment #10 from rsandifo at gcc dot gnu.org gnu.org> --- > Might be a daft question, but which cases besides > INTEGER_CST are supposed to be captured by the CONSTANT_CLASS_P? For the bitops? I suppose FIXED_CST, VECTOR_CST, COMPLEX_CST (for _Complex int), basically all constants for which bitops are valid.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- (In reply to rsand...@gcc.gnu.org from comment #12) > (In reply to Andrew Pinski from comment #11) > > For bit_and/bit_ior, VECTOR_CST (I would assume). > Ah, yeah. But then I don't think a top-level POLY_INT_CST_P > cuts it. We'd have the same problem with VECTOR_CSTs containing > POLY_INT_CSTs. Do we really support that?
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #12 from rsandifo at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #11) > For bit_and/bit_ior, VECTOR_CST (I would assume). Ah, yeah. But then I don't think a top-level POLY_INT_CST_P cuts it. We'd have the same problem with VECTOR_CSTs containing POLY_INT_CSTs.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #11 from Andrew Pinski --- (In reply to rsand...@gcc.gnu.org from comment #10) > Might be a daft question, but which cases besides > INTEGER_CST are supposed to be captured by the CONSTANT_CLASS_P? For bit_and/bit_ior, VECTOR_CST (I would assume).
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #10 from rsandifo at gcc dot gnu.org --- Might be a daft question, but which cases besides INTEGER_CST are supposed to be captured by the CONSTANT_CLASS_P?
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #9 from Richard Biener --- (In reply to Andrew Pinski from comment #8) > (In reply to Andrew Pinski from comment #7) > > Fails even in GCC 11.1.0. > > It is due to match.pd's > > > > /* (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) */ > > (simplify > > (bit_and (bit_ior @0 CONSTANT_CLASS_P@1) CONSTANT_CLASS_P@2) > > (bit_ior (bit_and @0 @2) (bit_and @1 @2))) > > > > POLY_INT_CST is a CONSTANT_CLASS but does not simplify on the bit_and. > > So maybe it should include a ! on the (bit_and @1 @2) . > > Which then will go into a loop with: > (A | B) & (A | C) into A | (B & C) We expect these to always fold :/ If they don't for POLY_INTs then maybe add a (if (!POLY_INT_CST_P (...) guard. There are many patterns that are affected by this.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Fails even in GCC 11.1.0. > It is due to match.pd's > > /* (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) */ > (simplify > (bit_and (bit_ior @0 CONSTANT_CLASS_P@1) CONSTANT_CLASS_P@2) > (bit_ior (bit_and @0 @2) (bit_and @1 @2))) > > POLY_INT_CST is a CONSTANT_CLASS but does not simplify on the bit_and. > So maybe it should include a ! on the (bit_and @1 @2) . Which then will go into a loop with: (A | B) & (A | C) into A | (B & C)
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|12.3|---
Component|c++ |middle-end
Ever confirmed|0 |1
Last reconfirmed|2023-04-13 00:00:00 |2023-04-14
Summary|[12/13 Regression] Compiler |(t | 15) & svcntb() causes
|loops forever to OOM while |an OOM/ICE
|compiling |
|evaluate_prg_hwy.cc and SVE |
Known to fail||11.1.0, 13.0
--- Comment #7 from Andrew Pinski ---
Simple reduced testcase:
```
#include
unsigned long f(unsigned long tt)
{
unsigned long t= svcntb();
return (tt | 15) & t;
}
```
Confirmed.
Fails even in GCC 11.1.0.
It is due to match.pd's
/* (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) */
(simplify
(bit_and (bit_ior @0 CONSTANT_CLASS_P@1) CONSTANT_CLASS_P@2)
(bit_ior (bit_and @0 @2) (bit_and @1 @2)))
POLY_INT_CST is a CONSTANT_CLASS but does not simplify on the bit_and.
So maybe it should include a ! on the (bit_and @1 @2) .
