[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380
Kewen Lin changed:
What|Removed |Added
Keywords||wrong-code
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Kewen Lin ---
Should be fixed on trunk and gcc-{12,13}.
[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:a570462419f5a6ba2880a82d6394419864bd035b commit r12-9926-ga570462419f5a6ba2880a82d6394419864bd035b Author: Kewen Lin Date: Sun Oct 15 21:08:29 2023 -0500 rs6000: Use default target option node for callee by default [PR111380] As PR111380 (and the discussion in related PRs) shows, for now how function rs6000_can_inline_p treats the callee without any target option node is wrong. It considers it's always safe to inline this kind of callee, but actually its target flags are from the command line options (target_option_default_node), it's possible that the flags of callee don't satisfy the condition of inlining, but it is still inlined, then result in unexpected consequence. As the associated test case pr111380-1.c shows, the caller main is attributed with power8, but the callee foo is compiled with power9 from command line, it's unexpected to make main inline foo since foo can contain something that requires power9 capability. Without this patch, for lto (with -flto) we can get error message (as it forces the callee to have a target option node), but for non-lto, it's inlined unexpectedly. This patch is to make callee adopt target_option_default_node when it doesn't have a target option node, it can avoid wrong inlining decision and fix the inconsistency between LTO and non-LTO. It also aligns with what the other ports do. PR target/111380 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_can_inline_p): Adopt target_option_default_node when the callee has no option attributes, also simplify the existing code accordingly. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr111380-1.c: New test. * gcc.target/powerpc/pr111380-2.c: New test. (cherry picked from commit 266dfed68b881702e9660889f63408054b7fa9c0)
[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380 --- Comment #2 from CVS Commits --- The releases/gcc-13 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:cc87aaeceea58389b681e3a6a63f95e54f2b59cd commit r13-7954-gcc87aaeceea58389b681e3a6a63f95e54f2b59cd Author: Kewen Lin Date: Sun Oct 15 21:05:47 2023 -0500 rs6000: Use default target option node for callee by default [PR111380] As PR111380 (and the discussion in related PRs) shows, for now how function rs6000_can_inline_p treats the callee without any target option node is wrong. It considers it's always safe to inline this kind of callee, but actually its target flags are from the command line options (target_option_default_node), it's possible that the flags of callee don't satisfy the condition of inlining, but it is still inlined, then result in unexpected consequence. As the associated test case pr111380-1.c shows, the caller main is attributed with power8, but the callee foo is compiled with power9 from command line, it's unexpected to make main inline foo since foo can contain something that requires power9 capability. Without this patch, for lto (with -flto) we can get error message (as it forces the callee to have a target option node), but for non-lto, it's inlined unexpectedly. This patch is to make callee adopt target_option_default_node when it doesn't have a target option node, it can avoid wrong inlining decision and fix the inconsistency between LTO and non-LTO. It also aligns with what the other ports do. PR target/111380 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_can_inline_p): Adopt target_option_default_node when the callee has no option attributes, also simplify the existing code accordingly. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr111380-1.c: New test. * gcc.target/powerpc/pr111380-2.c: New test. (cherry picked from commit 266dfed68b881702e9660889f63408054b7fa9c0)
[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380 --- Comment #1 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:266dfed68b881702e9660889f63408054b7fa9c0 commit r14-4246-g266dfed68b881702e9660889f63408054b7fa9c0 Author: Kewen Lin Date: Mon Sep 25 00:27:59 2023 -0500 rs6000: Use default target option node for callee by default [PR111380] As PR111380 (and the discussion in related PRs) shows, for now how function rs6000_can_inline_p treats the callee without any target option node is wrong. It considers it's always safe to inline this kind of callee, but actually its target flags are from the command line options (target_option_default_node), it's possible that the flags of callee don't satisfy the condition of inlining, but it is still inlined, then result in unexpected consequence. As the associated test case pr111380-1.c shows, the caller main is attributed with power8, but the callee foo is compiled with power9 from command line, it's unexpected to make main inline foo since foo can contain something that requires power9 capability. Without this patch, for lto (with -flto) we can get error message (as it forces the callee to have a target option node), but for non-lto, it's inlined unexpectedly. This patch is to make callee adopt target_option_default_node when it doesn't have a target option node, it can avoid wrong inlining decision and fix the inconsistency between LTO and non-LTO. It also aligns with what the other ports do. PR target/111380 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_can_inline_p): Adopt target_option_default_node when the callee has no option attributes, also simplify the existing code accordingly. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr111380-1.c: New test. * gcc.target/powerpc/pr111380-2.c: New test.
[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-09-12 Target||powerpc*-linux-gnu
