public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Martin Jambor <mjambor@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 4/9] ipa-sra: Treat REFERENCE_TYPES as always dereferencable
Date: Mon, 12 Dec 2022 22:47:36 +0100	[thread overview]
Message-ID: <Y5eheDl3x4zGBi6A@kam.mff.cuni.cz> (raw)
In-Reply-To: <ri6359kimxk.fsf@suse.cz>

> Hi,
> 
> I'm re-posting patches which I have posted at the end of stage 1 but
> which have not passed review yet.
> 
> 8<--------------------------------------------------------------------
> 
> C++ and especially Fortran pass data by references which are not
> pointers potentially pointing anywhere and so can be assumed to be
> safely dereferencable.  This patch teaches IPA-SRA to treat them as
> such and avoid the dance we do to prove that we can move loads from
> them to the caller.
> 
> When we do not know that a dereference will happen all the time, we
> need a heuristics so that we do not force memory accesses that normally
> happen only rarely.  The patch simply uses the (possibly guessed)
> profile and checks whether the (expected) number of loads is at least
> half of function invocations invocations.
> 
> Bootstrapped and tested individually when I originally posted it and
> now bootstrapped and LTO-bootstrapped and tested as part of the whole
> series.  OK for master?
> 
> 
> gcc/ChangeLog:
> 
> 2022-11-11  Martin Jambor  <mjambor@suse.cz>
> 
> 	PR ipa/103585
> 	* ipa-sra.c (struct gensum_param_access): New field load_count.
> 	(struct gensum_param_desc): New field safe_ref, adjusted comments.
> 	(by_ref_count): Renamed to unsafe_by_ref_count, adjusted all uses.
> 	(dump_gensum_access): Dump the new field.
> 	(dump_gensum_param_descriptor): Likewise.
> 	(create_parameter_descriptors): Set safe_ref field, move setting
> 	by_ref forward.  Only increment unsafe_by_ref_count for unsafe
> 	by_ref parameters.
> 	(allocate_access): Initialize new field.
> 	(mark_param_dereference): Adjust indentation.  Only add data to
> 	bb_dereferences for unsafe by_ref parameters.
> 	(scan_expr_access): For loads, accumulate BB counts.
> 	(dereference_probable_p): New function.
> 	(check_gensum_access): Fix leading comment, add parameter FUN.
> 	Check cumulative counts of loads for safe by_ref accesses instead
> 	of dereferences.
> 	(process_scan_results): Do not propagate dereference distances for
> 	safe by_ref parameters.  Pass fun to check_gensum_access.  Safe
> 	by_ref params do not need the postdominance check.
> 
> gcc/testsuite/ChangeLog:
> 
> 2022-11-11  Martin Jambor  <mjambor@suse.cz>
> 
>         * g++.dg/ipa/ipa-sra-5.C: New test
> -/* Perform basic checks on ACCESS to PARM described by DESC and all its
> -   children, return true if the parameter cannot be split, otherwise return
> -   true and update *TOTAL_SIZE and *ONLY_CALLS.  ENTRY_BB_INDEX must be the
> -   index of the entry BB in the function of PARM.  */
> +/* Return true if the ACCESS loads happen frequently enough in FUN to risk
> +   moving them to the caller and only pass the result.  */
>  
>  static bool
> -check_gensum_access (tree parm, gensum_param_desc *desc,
> +dereference_probable_p (struct function *fun, gensum_param_access *access)
> +{
> +  return access->load_count
> +    >= ENTRY_BLOCK_PTR_FOR_FN (fun)->count.apply_scale (1, 2);

We may want to have --param for this.

Otherwise the patch is OK.
Honza

  reply	other threads:[~2022-12-12 21:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-12 16:52 Martin Jambor
2022-12-12 21:47 ` Jan Hubicka [this message]
2022-12-13 18:37   ` Martin Jambor

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=Y5eheDl3x4zGBi6A@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mjambor@suse.cz \
    /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).