public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: <gcc-patches@gcc.gnu.org>, Jakub Jelinek <jakub@redhat.com>
Cc: Cesar Philippidis <cesar@codesourcery.com>
Subject: Re: OMP_CLAUSES with clauses in operand 0
Date: Wed, 29 Apr 2015 11:14:00 -0000	[thread overview]
Message-ID: <877fsvrxuu.fsf@schwinge.name> (raw)
In-Reply-To: <20150429093231.GD1751@tucnak.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

Hi!

On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
> where it is used.

Huh.  OMP_CLAUSES is currently used in a dozen places in
cp/cp-gimplify.c, cp/pt.c, and gimplify.c.  I've been expecting my
changed code to be well-optimizable, for the compiler already knows
TREE_CODE(NODE) in a lot of these places.  Doing a quick before (1)/after
(2) comparison test with -g -O2 on x86_64 GNU/Linux using GCC 4.8.3, the
object file sizes are as follows:

       text    data     bss     dec     hex filename
      37027       0      16   37043    90b3 1/build-gcc/gcc/cp/cp-gimplify.o
      36307       0      16   36323    8de3 2/build-gcc/gcc/cp/cp-gimplify.o
       text    data     bss     dec     hex filename
     458742       0     136  458878   7007e 1/build-gcc/gcc/cp/pt.o
     458630       0     136  458766   7000e 2/build-gcc/gcc/cp/pt.o
       text    data     bss     dec     hex filename
     166056       0      48  166104   288d8 1/build-gcc/gcc/gimplify.o
     166200       0      48  166248   28968 2/build-gcc/gcc/gimplify.o

..., so actually smaller for the first two files.  Admittedly, there is a
144 bytes (0.0867 %) size increase in gimplify.o, and I have not measured
the actual runtime overhead (which I'm totally expecting to be "in the
noise", but...), so I'm assuming that my proposal to keep the interface
simple does not pay for the presumed runtime overhead, so I guess I'm
posting this patch just for the archives...

--- gcc/tree.h
+++ gcc/tree.h
@@ -1200,7 +1200,9 @@ extern void protected_set_expr_location (tree, location_t);
 #define OMP_BODY(NODE) \
   TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_CRITICAL), 0)
 #define OMP_CLAUSES(NODE) \
-  TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1)
+  ((TREE_CODE (NODE) <= OMP_SINGLE) \
+   ? TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \
+   : TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_CACHE, OMP_TARGET_UPDATE), 0))
 
 #define OACC_PARALLEL_BODY(NODE) \
   TREE_OPERAND (OACC_PARALLEL_CHECK (NODE), 0)

If that's not been obvious, I favor code readability (one generic
OMP_CLAUSES interface instead of having both OMP_CLAUSES and
OMP_CLAUSES_STANDALONE) over a tiny code size regression, but you seem to
think differently, set a different policy for code changes, which I'll
have to yield to.


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]

  reply	other threads:[~2015-04-29 11:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <553E695A.2070007@mentor.com>
     [not found] ` <87zj5ttqpz.fsf@schwinge.name>
     [not found]   ` <553E787A.1020109@mentor.com>
2015-04-28 19:30     ` Fix OpenMP's target update directive in templated code Thomas Schwinge
2015-04-29  9:00       ` Jakub Jelinek
2015-04-29  9:30         ` Thomas Schwinge
2015-04-29  9:32         ` OMP_CLAUSES with clauses in operand 0 (was: Fix OpenMP's target update directive in templated code) Thomas Schwinge
2015-04-29 10:06           ` Jakub Jelinek
2015-04-29 11:14             ` Thomas Schwinge [this message]
2015-04-29 11:55               ` OMP_CLAUSES with clauses in operand 0 Jakub Jelinek
2015-04-29 14:37                 ` Thomas Schwinge
2015-04-29 14:52                   ` Jakub Jelinek
2015-04-29 15:46                     ` Thomas Schwinge
2015-04-29 16:04                       ` Jakub Jelinek
2015-04-29 16:07                         ` Thomas Schwinge

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=877fsvrxuu.fsf@schwinge.name \
    --to=thomas@codesourcery.com \
    --cc=cesar@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /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).