public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Richard Biener <rguenther@suse.de>
Subject: Re: [PATCH] ipa: call destructors on lattices before freeing them (PR 113476)
Date: Wed, 14 Feb 2024 10:52:57 +0100	[thread overview]
Message-ID: <ri6eddfz81y.fsf@virgil.suse.cz> (raw)
In-Reply-To: <ZcpablJP2iT8Rsn8@kam.mff.cuni.cz>

Hi,

On Mon, Feb 12 2024, Jan Hubicka wrote:
>> Hi,
>> 
>> In PR 113476 we have discovered that ipcp_param_lattices is no longer
>> a POD and should be destructed.  This patch does that, calling
>> destructor on each element of the array containing them when the
>> corresponding summary of a node is freed.  An alternative would be to
>> change the XCNEWVEC-and-placement-new to initializations in
>> constructors of all things in ipcp_param_lattices and then simply use
>> normal operators new and delete.  I am not sure, the initialization
>> through XCNEWVEC may be a bit more efficient although that is probably
>> not a big concern.  In the end, I opted for a simpler solution for
>> stage 4.
>> 
>> I have verified that valgrind no longer reports lost memory blocks
>> allocated within ipcp_vr_lattice::meet_with_1 on the preprocessed source
>> (dwarf2out.i) attached to Bugzilla.  The patch also passes bootstrap and
>> LTO bootstrap and testing on x86_64-linux.
>> 
>> OK for master?
>> 
>> Thanks,
>> 
>> Martin
>> 
>> 
>> gcc/ChangeLog:
>> 
>> 2024-02-09  Martin Jambor  <mjambor@suse.cz>
>> 
>> 	PR tree-optimization/113476
>> 	* ipa-prop.h (ipa_node_params::~ipa_node_params): Moved...
>> 	* ipa-cp.cc (ipa_node_params::~ipa_node_params): ...here.  Added
>> 	destruction of lattices.
>
> OK.
> So you do not use vectors (which would also handle the destruction)
> basically to save space needed to keep the
> size of the vector since that is known from the parameter count?
>

OK, so when I started looking at converting lattices to vector, it
immediately became clear why it is an array.  The type of the element of
the array (ipcp_param_lattices and all it contains) is only forward
declared in ipa-prop.h where ipa_node_params is defined which can
therefore just contain a pointer.  The actual definition of
ipcp_param_lattices is then done only in ipa-cp.c.

Converting the array to a vector would means moving ipcp_param_lattices
together with ipcp_lattice, ipcp_value, ipcp_value_base,
ipcp_agg_lattice, ipcp_bits_lattice, ipcp_vr_lattice from ipa-cp.c to
ipa-prop.h.  Or an ipa-cp.h which ipa-prop.h would require/include.  But
perhaps that is the proper C++ thing to do :-/

Martin

      parent reply	other threads:[~2024-02-14  9:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 17:39 Martin Jambor
2024-02-12 17:50 ` Jan Hubicka
2024-02-12 18:17   ` Martin Jambor
2024-02-12 20:22     ` Jan Hubicka
2024-02-13 17:49       ` Martin Jambor
2024-02-19 15:04         ` [PATCH] ipa: Convert lattices from pure array to vector " Martin Jambor
2024-02-20  7:11           ` Richard Biener
2024-02-20 10:20           ` Jan Hubicka
2024-02-14  9:52   ` Martin Jambor [this message]

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=ri6eddfz81y.fsf@virgil.suse.cz \
    --to=mjambor@suse.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=rguenther@suse.de \
    /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: link
Be 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).