From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26802 invoked by alias); 29 Apr 2015 11:44:04 -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 25855 invoked by uid 89); 29 Apr 2015 11:44:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 29 Apr 2015 11:44:03 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3TBi0Vx022171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Apr 2015 07:44:00 -0400 Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3TBhwZk014433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Apr 2015 07:43:59 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t3TBhvNE017400; Wed, 29 Apr 2015 13:43:57 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t3TBht1V017399; Wed, 29 Apr 2015 13:43:55 +0200 Date: Wed, 29 Apr 2015 11:55:00 -0000 From: Jakub Jelinek To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org, Cesar Philippidis Subject: Re: OMP_CLAUSES with clauses in operand 0 Message-ID: <20150429114355.GF1751@tucnak.redhat.com> Reply-To: Jakub Jelinek 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> <877fsvrxuu.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877fsvrxuu.fsf@schwinge.name> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01862.txt.bz2 On Wed, Apr 29, 2015 at 01:13:29PM +0200, Thomas Schwinge wrote: > 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... I really don't understand how you could get smaller code out of that, that doesn't make any sense. And I don't see where it would make sense to share the same code for handling the standalone directives and directives with associated blocks, in all the places I've looked at you want a different code. And in many cases you don't have just a single TREE_CODE, but multiple, likely all of them from the same category (either all of them smaller/equal or all larger than OMP_SINGLE), but VRP doesn't have to be able to fix up the weirdnesses. So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for everything. And, tree checking which is on by default should catch this properly, it was just a matter of tests not being written when they should have been. Jakub