From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28817 invoked by alias); 21 May 2015 13:38:46 -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 28805 invoked by uid 89); 21 May 2015 13:38:45 -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; Thu, 21 May 2015 13:38:35 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YvQgB-0005zi-KA from Julian_Brown@mentor.com ; Thu, 21 May 2015 06:38:31 -0700 Received: from octopus (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.3.224.2; Thu, 21 May 2015 14:38:26 +0100 Date: Thu, 21 May 2015 13:42:00 -0000 From: Julian Brown To: Jakub Jelinek CC: Bernd Schmidt , GCC Patches Subject: Re: [gomp4] Vector-single predication Message-ID: <20150521143819.5bfa89b0@octopus> In-Reply-To: <20150521132154.GU1751@tucnak.redhat.com> References: <555DC493.2050208@codesourcery.com> <20150521115700.GT1751@tucnak.redhat.com> <20150521140512.22b34bbf@octopus> <20150521132154.GU1751@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01965.txt.bz2 On Thu, 21 May 2015 15:21:54 +0200 Jakub Jelinek wrote: > On Thu, May 21, 2015 at 02:05:12PM +0100, Julian Brown wrote: > > OpenACC handles function calls specially (calling them "routines" > > -- of varying sorts, gang, worker, vector or seq, affecting where > > they can be invoked from). The plan is that all threads will call > > such routines -- and then some threads will be "neutered" as > > appropriate within the routines themselves, as appropriate. > > All functions will behave that way, or just some using some magic > attribute etc.? Say will newlib functions behave this way (math > functions, printf, ...)? It's actually unclear at this point if "regular" functions are supported by OpenACC at all (the spec says nothing about them). They probably raise "interesting" questions about re-entrancy, synchronisation, and so on. > For math functions e.g. it would be nice if > they could behave both ways (perhaps as separate entrypoints), so > have the possibility to say how many threads from the warp will > perform the operation and then work on array arguments and array > return value (kind like OpenMP or Cilk+ elemental functions, just > perhaps with different argument/return value passing conventions). And that's something that's way outside the spec as currently defined, AFAIK. Julian