[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2024-10-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 Bug 110015 depends on bug 112418, which changed state. Bug 112418 Summary: factor_out_conditional_operation could be done for more phis https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112418 What|Removed |Added --

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2024-10-19 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #11 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:8d6d6d537fdc754a429b08091422c307188f3c82 commit r15-4503-g8d6d6d537fdc754a429b08091422c307188f3c82 Author: Andrew Pinski Date: W

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-11-24 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #10 from Jan Hubicka --- runtimes on zen4 hardware. trunk -O3 -flto -march-native 42171 42964 42106 clang -O3 -flto -march=native 37393 37423 37508 gcc 13 -O3 -flto -march=native

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #9 from Andrew Pinski --- I should note that PR 112416 is not needed to vectorize the loop, though it would improve code.

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 Andrew Pinski changed: What|Removed |Added Depends on||112418 --- Comment #8 from Andrew Pinsk

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Severity|normal

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 Andrew Pinski changed: What|Removed |Added Depends on||112416 --- Comment #6 from Andrew Pinsk

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #5 from Andrew Pinski --- After fixing PR 112324 (and a secondary patch to phiopt to do factor_out_conditional_operation for all phi nodes rather than just a single one) we still miss the abs detection: _34 = tmp_24 < 0; _55 = (

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-10-31 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #4 from Hongtao.liu --- > So here we have a reduction for MAX_EXPR, but there's 2 MAX_EXPR which can > be merge together with MAX_EXPR > > Create pr112324.

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-10-31 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #3 from Hongtao.liu --- 169test.c:85:23: note: vect_is_simple_use: operand max_38 = PHI , type of def: unknown 170test.c:85:23: missed: Unsupported pattern. 171test.c:62:24: missed: not vectorized: unsupported use in stmt. 172t

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-10-31 Thread zhangjungcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 jun zhang changed: What|Removed |Added CC||zhangjungcc at gmail dot com --- Comment #2

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

2023-05-28 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #1 from Jan Hubicka --- opj_t1_enc_refpass is not inlined due to large function growth and some others due to max-inline-insns-auto. With inlining forced I get profile: 87.35% opj_t1_cblk_encode_processor 6.22% opj_dwt_enco