public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kyrill Tkachov <kyrylo.tkachov@arm.com>
To: Christian Bruel <christian.bruel@st.com>,
	 Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, ARM]: Add TARGET_OPTION[RESTORE,SAVE,PRINT] hooks
Date: Fri, 04 Sep 2015 09:50:00 -0000	[thread overview]
Message-ID: <55E9644E.2080708@arm.com> (raw)
In-Reply-To: <55E6BD35.5020601@st.com>

Hi Christian,

Thanks again for working on this!

On 02/09/15 10:11, Christian Bruel wrote:
> Hi,
>
> This patch uses TARGET_OPTION_RESTORE and SAVE to switch the attribute
> target dependent params between functions.
>
> This is more efficient than arm_option_params_internal, and prepares the
> ground for the other machine target attributes.

To be honest, I'm reluctant to take this approach.
The design I'd like to see is for us to figure out the minimal set
of TargetSave variables (and options in arm.opt that require the tag Save)
and use them to 'package' the backend state whenever needed, with the help
of TARGET_OPTION_SAVE when appropriate.

Then during TARGET_OPTION_RESTORE we would call arm_option_override_internal
and arm_option_params_internal to restore all the different backend
variables that we need.

In my opinion that is the approach that would give the most maintainability.
In any case, I see arm_option_params_internal is not particularly complicated
at the moment, so I don't think your patch would show any noticeable speed improvement
(unless you can share data to demonstrate that :))

Maybe we can make the roadmap for this more concrete if you post a description of
what parameters you'd like to save and restore to achieve this goal and we can discuss
that. Some that come to mind would be: CPU we're tuning for, architecture, FPU, and
basically any option in arm.opt which we want to allow to vary on a per-function basis
(i.e. no ABI-changing options).

Hope this helps,

Kyrill

P.S.
I recently implemented this functionality in the aarch64 backend.
Maybe the implementation of these hooks over there could be of some help
(though I appreciate the arm backend is more complicated with more legacy and option variations)

> No regressions. OK for trunk ?
>
> many thanks
>
> Christian
>

Index: gcc/config/arm/arm.c
===================================================================
--- gcc/config/arm/arm.c	(revision 227366)
+++ gcc/config/arm/arm.c	(working copy)
@@ -245,9 +245,14 @@
  static void arm_expand_builtin_va_start (tree, rtx);
  static tree arm_gimplify_va_arg_expr (tree, tree, gimple_seq *, gimple_seq *);
  static void arm_option_override (void);
+static void arm_option_print (FILE *, int, struct cl_target_option *);
  static void arm_set_current_function (tree);
  static bool arm_can_inline_p (tree, tree);
  static bool arm_valid_target_attribute_p (tree, tree, tree, int);
+static void arm_function_specific_save (struct cl_target_option *,
+					struct gcc_options *);
+static void arm_function_specific_restore (struct gcc_options *,
+					   struct cl_target_option *);


I'd rather call them arm_option_save and arm_option_restore.
That way it's easy to deduce that they implement TARGET_OPTION_{SAVE,RESTORE}.

  reply	other threads:[~2015-09-04  9:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02  9:11 Christian Bruel
2015-09-04  9:50 ` Kyrill Tkachov [this message]
2015-09-04 11:23   ` Christian Bruel

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=55E9644E.2080708@arm.com \
    --to=kyrylo.tkachov@arm.com \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=christian.bruel@st.com \
    --cc=gcc-patches@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: 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).