public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/111157] [14 Regression] 416.gamess fails with a run-time abort when compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4 Date: Mon, 30 Oct 2023 17:38:26 +0000 [thread overview] Message-ID: <bug-111157-4-j9c0WE9f6u@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-111157-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111157 --- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Martin Jambor <jamborm@gcc.gnu.org>: https://gcc.gnu.org/g:997c8219f020091d00fd225c81270aa551bfe9e4 commit r14-5017-g997c8219f020091d00fd225c81270aa551bfe9e4 Author: Martin Jambor <mjambor@suse.cz> Date: Mon Oct 30 18:34:59 2023 +0100 ipa: Prune any IPA-CP aggregate constants known by modref to be killed (111157) PR 111157 shows that IPA-modref and IPA-CP (when plugged into value numbering) can optimize out a store both before a call (because the call will overwrite it) and in the call (because the store is of the same value) and by eliminating both create miscompilation. This patch fixes that by pruning any constants from the list of IPA-CP aggregate value constants that it knows the contents of the memory can be "killed." Unfortunately, doing so is tricky. First, IPA-modref loads override kills and so only stores not loaded are truly not necessary. Looking stuff up there means doing what most of what modref_may_alias may do but doing exactly what it does is tricky because it takes also aliasing into account and has bail-out counters. To err on the side of caution in order to avoid this miscompilation we have to prune a constant when in doubt. However, pruning can interfere with the mechanism of how clone materialization distinguishes between the cases when a parameter was entirely removed and when it was both IPA-CPed and IPA-SRAed (in order to make up for the removal in debug info, which can bump into an assert when compiling g++.dg/torture/pr103669.C when we are not careful). Therefore this patch: 1) marks constants that IPA-modref has in its kill list with a new "killed" flag, and 2) prunes the list from entries with this flag after materialization and IPA-CP transformation is done using the template introduced in the previous patch It does not try to look up anything in the load lists, this will be done as a follow-up in order to ease review. gcc/ChangeLog: 2023-10-27 Martin Jambor <mjambor@suse.cz> PR ipa/111157 * ipa-prop.h (struct ipa_argagg_value): Newf flag killed. * ipa-modref.cc (ipcp_argagg_and_kill_overlap_p): New function. (update_signature): Mark any any IPA-CP aggregate constants at positions known to be killed as killed. Move check that there is clone_info after this pruning. * ipa-cp.cc (ipa_argagg_value_list::dump): Dump the killed flag. (ipa_argagg_value_list::push_adjusted_values): Clear the new flag. (push_agg_values_from_plats): Likewise. (ipa_push_agg_values_from_jfunc): Likewise. (estimate_local_effects): Likewise. (push_agg_values_for_index_from_edge): Likewise. * ipa-prop.cc (write_ipcp_transformation_info): Stream the killed flag. (read_ipcp_transformation_info): Likewise. (ipcp_get_aggregate_const): Update comment, assert that encountered record does not have killed flag set. (ipcp_transform_function): Prune all aggregate constants with killed set. gcc/testsuite/ChangeLog: 2023-09-18 Martin Jambor <mjambor@suse.cz> PR ipa/111157 * gcc.dg/lto/pr111157_0.c: New test. * gcc.dg/lto/pr111157_1.c: Second file of the same new test.
next prev parent reply other threads:[~2023-10-30 17:38 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-08-25 14:30 [Bug ipa/111157] New: " jamborm at gcc dot gnu.org 2023-08-25 15:57 ` [Bug ipa/111157] [14 Regression] " pinskia at gcc dot gnu.org 2023-08-25 16:46 ` jamborm at gcc dot gnu.org 2023-08-25 17:14 ` jamborm at gcc dot gnu.org 2023-08-25 20:07 ` jamborm at gcc dot gnu.org 2023-08-26 11:50 ` hubicka at gcc dot gnu.org 2023-08-28 7:18 ` rguenth at gcc dot gnu.org 2023-08-28 12:12 ` jamborm at gcc dot gnu.org 2023-08-28 12:16 ` jamborm at gcc dot gnu.org 2023-08-29 11:32 ` hubicka at ucw dot cz 2023-10-05 12:22 ` jamborm at gcc dot gnu.org 2023-10-17 12:28 ` rguenth at gcc dot gnu.org 2023-10-30 17:38 ` cvs-commit at gcc dot gnu.org 2023-10-30 17:38 ` cvs-commit at gcc dot gnu.org [this message] 2023-10-30 17:41 ` jamborm at gcc dot gnu.org 2023-10-31 7:43 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-111157-4-j9c0WE9f6u@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).