From patchwork Thu Mar 27 13:23:54 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 334334 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 928E314008C for ; Fri, 28 Mar 2014 00:24:15 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:reply-to:mime-version:content-type; q=dns; s=default; b=cj8i914fjbfQ2zlw0gprP9nnyOLYjg+rhSyqib8xqHu Tc7K6gMt5Ov123OPCtUouH8sEQrgdAilgTqq+/VcibaydOK2ZGMTo4nZ/FBjOOtj jyRovCr7mAkm8QYg4bXQ13CDOuFifTmYm5b1rF4mYOJ9gJuLfCG1F01ajDwG/8UY = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:reply-to:mime-version:content-type; s=default; bh=Z2ULEY/Im4WU692MS1VPeI8/gVY=; b=EaEMNZhheu/NnJqld Z1igw10Np8Jj4tpWnAvxulsPgP3rF1WDzv6i98fe7ToyNDmA/hgC04FpeVoAHhdS RfckMvZOycbMKjogRFiiKoo68f4juO+2V3AIaO+PiYCly4GDv/0av2Td+D0EJ+uZ TKF7pz0eA5ITvtTHb4Kyg+Cxjw= Received: (qmail 10409 invoked by alias); 27 Mar 2014 13:24:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 10393 invoked by uid 89); 27 Mar 2014 13:24:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham 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 ESMTP; Thu, 27 Mar 2014 13:24:00 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2RDNxZE030945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Mar 2014 09:23:59 -0400 Received: from tucnak.zalov.cz (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2RDNvjo027194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Mar 2014 09:23:59 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.8/8.14.7) with ESMTP id s2RDNuVI010184 for ; Thu, 27 Mar 2014 14:23:56 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.8/8.14.8/Submit) id s2RDNsfO010183 for gcc-patches@gcc.gnu.org; Thu, 27 Mar 2014 14:23:54 +0100 Date: Thu, 27 Mar 2014 14:23:54 +0100 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org Subject: [committed] Fix #pragma omp simd ICE (PR middle-end/60682) Message-ID: <20140327132354.GX1817@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Hi! gimplify_regimplify_operands doesn't grok gimple_clobber_p stmts very well (tries to regimplify the CONSTRUCTOR), but in the only case where we might need to regimplify them in omp-low.c (the addressable local vars in simd regions, remember this is before inlining) the clobbers actually don't serve any good, the vars are laid out into the magic arrays anyway and if vectorized the vectorizer drops the clobbers anyway, so I think there is no need to preserve the clobbers. Other possibility would be to gimplify it into temporary = &foo_simd_array[bar]; MEM_REF =v {CLOBBER}; but that might even prevent vectorization. Tested on x86_64-linux, committed to trunk. 2014-03-27 Jakub Jelinek PR middle-end/60682 * omp-low.c (lower_omp_1): For gimple_clobber_p stmts, if they need regimplification, just drop them instead of calling gimple_regimplify_operands on them. * g++.dg/gomp/pr60682.C: New test. Jakub --- gcc/omp-low.c.jj 2014-03-18 10:24:08.000000000 +0100 +++ gcc/omp-low.c 2014-03-27 13:47:49.474233639 +0100 @@ -10124,7 +10124,20 @@ lower_omp_1 (gimple_stmt_iterator *gsi_p if ((ctx || task_shared_vars) && walk_gimple_op (stmt, lower_omp_regimplify_p, ctx ? NULL : &wi)) - gimple_regimplify_operands (stmt, gsi_p); + { + /* Just remove clobbers, this should happen only if we have + "privatized" local addressable variables in SIMD regions, + the clobber isn't needed in that case and gimplifying address + of the ARRAY_REF into a pointer and creating MEM_REF based + clobber would create worse code than we get with the clobber + dropped. */ + if (gimple_clobber_p (stmt)) + { + gsi_replace (gsi_p, gimple_build_nop (), true); + break; + } + gimple_regimplify_operands (stmt, gsi_p); + } break; } } --- gcc/testsuite/g++.dg/gomp/pr60682.C.jj 2014-03-27 14:03:16.889205684 +0100 +++ gcc/testsuite/g++.dg/gomp/pr60682.C 2014-03-27 14:02:39.000000000 +0100 @@ -0,0 +1,44 @@ +// PR middle-end/60682 +// { dg-do compile } +// { dg-options "-O2 -fopenmp-simd" } + +struct A +{ + float a; + A () {} + A (const A &x) { a = x.a; } +}; + +struct B +{ + A a[16]; +}; + +struct C +{ + float a[1]; + C () {} + C (const C &x) { a[0] = x.a[0]; } +}; + +struct D +{ + C a[16]; +}; + +void +foo (int x, B &y, D &z) +{ +#pragma omp simd + for (int i = 0; i < x; ++i) + { + A a; + y.a[i] = a; + } +#pragma omp simd + for (int i = 0; i < x; ++i) + { + C a; + z.a[i] = a; + } +}