From patchwork Thu Jun 8 21:40:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cesar Philippidis X-Patchwork-Id: 773527 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 3wkJsh4XtWz9s7B for ; Fri, 9 Jun 2017 07:46:46 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="n/gIFDrS"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :subject:to:message-id:date:mime-version:content-type; q=dns; s= default; b=Idtgsb1ChK3jh/2I5eoBmtj3xWQ76ynVTHV8UZbgpxkhz3fXAPKw2 DuTkX3zV7uJpk0rVYscFk1pZM/0uoEvraskd7Cb0aYUTGO3A9V6nj7/De3qprPor JwBXWf58u8e5qHlnDGopprmPgR4M+sgvKYQJ+U5Rjx4KFKCcNRd+yU= 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:from :subject:to:message-id:date:mime-version:content-type; s= default; bh=R0Xx/Fu4daxpBnoElcWC4PfWXr0=; b=n/gIFDrSY81T2oU49y/T 8hl+/ZqtUPzYyu0lc51tFtVHufo3QkgJe2YQWE/Lh9uhm831MsZ4ygOogail0b1h ntn7ZyNT3nhUWE/8QjZ42xIm5eStGbzV+jsXCfRhGQHjq36I07eLm1E+7FG6lu+M olvb2OP14gF+5YofhV6Npjg= Received: (qmail 25046 invoked by alias); 8 Jun 2017 21:46:22 -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 24972 invoked by uid 89); 8 Jun 2017 21:46:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy=gang, cesar, n0, n10 X-Spam-User: qpsmtpd, 2 recipients 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, 08 Jun 2017 21:46:18 +0000 Received: from svr-orw-mbx-04.mgc.mentorg.com ([147.34.90.204]) by relay1.mentorg.com with esmtp id 1dJ5CM-0004IH-Pa from Cesar_Philippidis@mentor.com ; Thu, 08 Jun 2017 14:42:35 -0700 Received: from [127.0.0.1] (147.34.91.1) by SVR-ORW-MBX-04.mgc.mentorg.com (147.34.90.204) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Jun 2017 14:40:30 -0700 From: Cesar Philippidis Subject: [gomp4] Properly handle allocatable scalars in acc update. To: "gcc-patches@gcc.gnu.org" , Fortran List Message-ID: <8040a294-6ab1-6705-5a8d-211a6f3ff356@codesourcery.com> Date: Thu, 8 Jun 2017 14:40:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 X-ClientProxiedBy: SVR-ORW-MBX-09.mgc.mentorg.com (147.34.90.209) To SVR-ORW-MBX-04.mgc.mentorg.com (147.34.90.204) This patch fixes a bug I introduced while adding support for allocatable scalars back in April. Before, gfc_trans_oacc_executable_directive would indiscriminately promote all GOMP_MAP_FIRSTPRIVATE_POINTER data mappings to GOMP_MAP_ALWAYS_POINTER, because for allocatable scalars the runtime needs to update the on-device values of both the data being pointed to and the pointer itself. The problem with this is that the allocatable scalar bit isn't propagated across subroutine calls. Clearly this indiscriminate update behavior is wrong because the pointer of dummy arguments may not get mapped onto the accelerator. In this patch, I introduced a new acc_update bit inside the gfc_omp_clauses struct to represent when allocatable scalars need special treatment. As it stands, gfc_trans_omp_clauses_1 already has too many arguments, so I thought this approach would be better. Now gfc_trans_omp_clauses_1 can handle the allocatable scalar update directly. I've applied this patch to gomp-4_0-branch. Cesar 2017-06-08 Cesar Philippidis gcc/fortran/ * gfortran.h gfc_omp_clauses: Add update_allocatable. * trans-openmp.c (gfc_trans_omp_clauses_1): Set update_allocatable bit in clauses. Remove GOMP_MAP_FIRSTPRIVATE_POINTER data map promotions for acc update. (gfc_trans_oacc_executable_directive): Use GOMP_MAP_ALWAYS_POINTER for allocatable scalar data clauses inside acc update directives. libgomp/ * testsuite/libgomp.oacc-fortran/allocatable-array-1.f90: New test. diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index 8ca9f8a..0290efe 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -1318,7 +1318,7 @@ typedef struct gfc_omp_clauses gfc_expr_list *tile_list; unsigned async:1, gang:1, worker:1, vector:1, seq:1, independent:1; unsigned wait:1, par_auto:1, gang_static:1, nohost:1, acc_collapse:1, bind:1; - unsigned if_present:1, finalize:1; + unsigned if_present:1, finalize:1, update_allocatable:1; locus loc; char bind_name[GFC_MAX_SYMBOL_LEN+1]; } diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c index d5e2250..ca41903 100644 --- a/gcc/fortran/trans-openmp.c +++ b/gcc/fortran/trans-openmp.c @@ -2133,6 +2133,10 @@ gfc_trans_omp_clauses_1 (stmtblock_t *block, gfc_omp_clauses *clauses, enum gomp_map_kind gmk = GOMP_MAP_FIRSTPRIVATE_POINTER; if (n->u.map_op == OMP_MAP_FORCE_DEVICEPTR) gmk = GOMP_MAP_POINTER; + else if (GFC_DECL_GET_SCALAR_ALLOCATABLE (decl) + && (n->sym->attr.oacc_declare_create) + && clauses->update_allocatable) + gmk = GOMP_MAP_ALWAYS_POINTER; node4 = build_omp_clause (input_location, OMP_CLAUSE_MAP); OMP_CLAUSE_SET_MAP_KIND (node4, gmk); @@ -3323,12 +3327,14 @@ gfc_trans_oacc_executable_directive (gfc_code *code) { stmtblock_t block; tree stmt, oacc_clauses; + gfc_omp_clauses *clauses = code->ext.omp_clauses; enum tree_code construct_code; switch (code->op) { case EXEC_OACC_UPDATE: construct_code = OACC_UPDATE; + clauses->update_allocatable = 1; break; case EXEC_OACC_ENTER_DATA: construct_code = OACC_ENTER_DATA; @@ -3344,20 +3350,7 @@ gfc_trans_oacc_executable_directive (gfc_code *code) } gfc_start_block (&block); - oacc_clauses = gfc_trans_omp_clauses (&block, code->ext.omp_clauses, - code->loc); - - /* Promote GOMP_MAP_FIRSTPRIVATE_POINTER to GOMP_MAP_ALWAYS_POINTER for - variables inside OpenACC update directives. */ - if (code->op == EXEC_OACC_UPDATE) - for (tree c = oacc_clauses; c; c = OMP_CLAUSE_CHAIN (c)) - { - if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP - && OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER) - OMP_CLAUSE_SET_MAP_KIND (c, GOMP_MAP_ALWAYS_POINTER); - } - - + oacc_clauses = gfc_trans_omp_clauses (&block, clauses, code->loc); stmt = build1_loc (input_location, construct_code, void_type_node, oacc_clauses); gfc_add_expr_to_block (&block, stmt); diff --git a/libgomp/testsuite/libgomp.oacc-fortran/allocatable-array-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/allocatable-array-1.f90 new file mode 100644 index 0000000..4fc7b02 --- /dev/null +++ b/libgomp/testsuite/libgomp.oacc-fortran/allocatable-array-1.f90 @@ -0,0 +1,28 @@ +! Ensure that dummy arguments of allocatable arrays don't cause +! "libgomp: [...] is not mapped" errors. + +program main + integer, parameter :: n = 40 + integer, allocatable :: ar(:,:,:) + integer :: i + + allocate (ar(1:n,0:n-1,0:n-1)) + !$acc enter data copyin (ar) + + !$acc update host (ar) + + !$acc update device (ar) + + call update_ar (ar, n) + + !$acc exit data copyout (ar) +end program main + +subroutine update_ar (ar, n) + integer :: n + integer, dimension (1:n,0:n-1,0:n-1) :: ar + + !$acc update host (ar) + + !$acc update device (ar) +end subroutine update_ar