From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42872 invoked by alias); 21 Jan 2016 11:39:33 -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 42813 invoked by uid 89); 21 Jan 2016 11:39:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-languages-length:1067, hammer, she X-HELO: smtp.ispras.ru Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.199.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Jan 2016 11:39:31 +0000 Received: from [10.10.3.121] (unknown [83.149.199.91]) by smtp.ispras.ru (Postfix) with ESMTP id 21E4E20402; Thu, 21 Jan 2016 14:39:28 +0300 (MSK) Date: Thu, 21 Jan 2016 11:39:00 -0000 From: Alexander Monakov To: Ilya Verbin cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, Martin Jambor , Thomas Schwinge , Kirill Yukhin Subject: Re: [hsa merge 07/10] IPA-HSA pass In-Reply-To: <20160120185330.GC49431@msticlxl57.ims.intel.com> Message-ID: References: <20160113173925.220029649@virgil.suse.cz> <20160113173925.776317025@virgil.suse.cz> <20160114125858.GE3017@tucnak.redhat.com> <20160115145323.GL3982@virgil.suse.cz> <20160115150149.GX3017@tucnak.redhat.com> <20160115160234.GO3982@virgil.suse.cz> <20160115160954.GZ3017@tucnak.redhat.com> <20160115163814.GB48907@msticlxl57.ims.intel.com> <20160115164522.GA3017@tucnak.redhat.com> <20160115180547.GC48907@msticlxl57.ims.intel.com> <20160120185330.GC49431@msticlxl57.ims.intel.com> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2016-01/txt/msg01615.txt.bz2 On Wed, 20 Jan 2016, Ilya Verbin wrote: > I agree that OpenMP doesn't guarantee that all target regions must be executed > on the device, but in this case a user can't be sure that some library function > always will offload (because the library might be replaced by fallback version), > and he/she will have to write something like: I think there should be a way to allow the OpenMP runtime deduce what data needs to be resynced on target region entries/exits in presence of fallback execution; explicit copying via map(from/to:...) is a too big hammer for that. I wonder if it was discussed. It would be nice to be able to apply the idea of "debug counters" to target region offloading in order to automatically bisect offload miscompilations: force fallback execution for target region entries for Nth and next executions; bisect by N to find the first incorrectly executing offload region. If the implementation cannot count on source program fully handling arbitrary fallbacks, this idea doesn't work in general. Alexander