This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: OMP_CLAUSES with clauses in operand 0
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Cesar Philippidis <cesar at codesourcery dot com>
- Date: Wed, 29 Apr 2015 13:43:55 +0200
- Subject: Re: OMP_CLAUSES with clauses in operand 0
- Authentication-results: sourceware.org; auth=none
- References: <553E695A dot 2070007 at mentor dot com> <87zj5ttqpz dot fsf at schwinge dot name> <553E787A dot 1020109 at mentor dot com> <87383kt7kx dot fsf at schwinge dot name> <20150429085332 dot GC1751 at tucnak dot redhat dot com> <87egn3s2p4 dot fsf at schwinge dot name> <20150429093231 dot GD1751 at tucnak dot redhat dot com> <877fsvrxuu dot fsf at schwinge dot name>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Apr 29, 2015 at 01:13:29PM +0200, Thomas Schwinge wrote:
> 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...
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