From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96834 invoked by alias); 29 Apr 2015 11:13:58 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 96818 invoked by uid 89); 29 Apr 2015 11:13:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Apr 2015 11:13:56 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YnPw8-0002g5-5i from Thomas_Schwinge@mentor.com ; Wed, 29 Apr 2015 04:13:52 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Wed, 29 Apr 2015 12:13:50 +0100 From: Thomas Schwinge To: , Jakub Jelinek CC: Cesar Philippidis Subject: Re: OMP_CLAUSES with clauses in operand 0 In-Reply-To: <20150429093231.GD1751@tucnak.redhat.com> References: <553E695A.2070007@mentor.com> <87zj5ttqpz.fsf@schwinge.name> <553E787A.1020109@mentor.com> <87383kt7kx.fsf@schwinge.name> <20150429085332.GC1751@tucnak.redhat.com> <87egn3s2p4.fsf@schwinge.name> <20150429093231.GD1751@tucnak.redhat.com> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Wed, 29 Apr 2015 11:14:00 -0000 Message-ID: <877fsvrxuu.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2015-04/txt/msg01858.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2471 Hi! On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek 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, locati= on_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) <=3D 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)) =20 #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=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 472 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVQLzZAAoJEPoxNhtoi6COZccH+gMqdhEobg3r2mBAkP/PGPHx +bj6kCfJ4sQ0eBFj19tHy9MkvsxyvQw2srU74xe33vIs60hhtczCIdnbHhJ76Kva 0cBygRDeEChkM35LvG6XRNNS531SwsWyd0j0aIP9lGOPF4aMS5DUghcahoqNQvbh 1/A2ObB5qh2LxlAxzG2jccNjG3PzyCUHM5S06/tFpW4NMGNBbN9QnFpfyYFsJd37 b90/PULboWcqrQzJbxPHIuVvaOEiI99P3G+LjkdlhF5Q8mzG8nWddDWEMfovs7yG 63BigaRQnYSu3577Jtb1QXg6uVKoNc0jiVei+6gW20bLkx3WWthluVzxV9DEuSA= =NPnj -----END PGP SIGNATURE----- --=-=-=--