From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60590 invoked by alias); 24 Jun 2015 13:11:18 -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 60574 invoked by uid 89); 24 Jun 2015 13:11:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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, 24 Jun 2015 13:11:16 +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 1Z7kSO-0000xY-1z from Bernd_Schmidt@mentor.com ; Wed, 24 Jun 2015 06:11:12 -0700 Received: from [127.0.0.1] (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, 24 Jun 2015 14:11:10 +0100 Message-ID: <558AAC68.4020607@codesourcery.com> Date: Wed, 24 Jun 2015 13:37:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jakub Jelinek CC: Thomas Schwinge , , Nathan Sidwell , Julian Brown Subject: Re: [gomp4] Preserve NVPTX "reconvergence" points References: <20150528150635.7bd5db23@octopus> <20150528142011.GN10247@tucnak.redhat.com> <87pp5kg3js.fsf@schwinge.name> <20150528150802.GO10247@tucnak.redhat.com> <5583E68A.9020608@codesourcery.com> <20150619122557.GO10247@tucnak.redhat.com> <5584132A.6080108@codesourcery.com> <20150619134529.GP10247@tucnak.redhat.com> In-Reply-To: <20150619134529.GP10247@tucnak.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg01703.txt.bz2 On 06/19/2015 03:45 PM, Jakub Jelinek wrote: > If the loop remains in the IL (isn't optimized away as unreachable or > isn't removed, e.g. as a non-loop - say if it contains a noreturn call), > the flags on struct loop should be still there. For the loop clauses > (reduction always, and private/lastprivate if addressable etc.) for > OpenMP simd / Cilk+ simd we use special arrays indexed by internal > functions, which then during vectorization are shrunk (but in theory could > be expanded too) to the right vectorization factor if vectorized, of course > accesses within the loop vectorized using SIMD, and if not vectorized, > shrunk to 1 element. I'd appreciate if you could describe that mechanism in more detail. As far as I can tell it is very poorly commented and documented in the code. I mean, it doesn't even follow the minimal coding standards of describing function inputs: /* Helper function of lower_rec_input_clauses, used for #pragma omp simd privatization. */ static bool lower_rec_simd_input_clauses (tree new_var, omp_context *ctx, int &max_vf, tree &idx, tree &lane, tree &ivar, tree &lvar) Bernd