From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id 3381A3858C35 for ; Tue, 27 Feb 2024 12:29:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3381A3858C35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=baylibre.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3381A3858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::331 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709036979; cv=none; b=nHkTzp7Ko9Sb2OtYiPWIQfkKUXt+gg0WJ/nKpCUe+LIm7EErhpBYpoS8X6xK4sChLYF8JDxFvRy9+v0CUJacKl0v6YuQuYl6adSnA+QpLZlMxewHU2v30WPbwY2N4prQ4vvuVu/YCx+kaYO6HV960p3pStP5PVJ+kru+8gyCI90= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709036979; c=relaxed/simple; bh=/u+mQnJ+ilPJ7VTjiAgBehlNWxZ4rXhiXphWjFZGtiM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=jdgqR8U0ew2YVaqgtwB/TD0g34GwvRJv2fBTmYeg+gm3NEjlrXlsPdeeiQbfu+ZBRa09UE6cXIVpJXz2++Otc/werllI2k+KPn3598LhZZ28HysCW+QsflSKnC+pUwCjwecLWuAt1Aua4hdmwMsZksBnFg9ixS743yaVkQvmT2o= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-412af1c91f3so2597855e9.1 for ; Tue, 27 Feb 2024 04:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1709036975; x=1709641775; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rMOQPjtEiaaIeNK5P60m6j03syGpU1TMKXKuNNmQsvY=; b=hFogl7OMqxVCw/KeNJ7e6+OqLvt+vmEJhjV0lGmLksSg5PfyuEYqmwksDWYuyV2j8W QTOzhk1XW+tPqlkNP6CLkINAnj/AadauhacatlXbCegZQsZJXMqny/aaT2gCjHrF/SG0 +b8Uf8R9ECx9G4pnIeSzCnXKDfD6qHL007jM96t9JM5n7jpK1wZJktecnEcM7ezwAYKF o8RQj+DYsylMq3/wt76UsNjBh1O/T5MCk6Ml0k2YY6gCqRQcKzcpShcFNYy6Q03VuRYc i+Y2ycwuYDhmbpGmlt+n9JLN3tkIXi42g54MrXJ93EOMmX66Hwdktm5MhMRGoaUJQZVf YM3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709036975; x=1709641775; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rMOQPjtEiaaIeNK5P60m6j03syGpU1TMKXKuNNmQsvY=; b=LUQTIzEZRN05kHFuDGy/aUQN7oYcymfxCzRmlgpkhxQvUgGsit0UpUuXKBC2uX8ULa S2Po3YTGivIyKtY9HK7xBEkXlMWZn/O2Eij3xFmS8lbWenmOrCeg//VjNf7l6sdcWqtG evPytL5px4QA4SgO+aNSwX5ny8ogp6boUD9oufk++CE8njHe2zjfBxvzEhpwqLgdmTry 4gRCTdWAgStkwbiPaFu/foxUxtWbzAqy4aYLwmI0tDCU7AdeeDIc0HDP4yOKgENp2/vu Xk/2FI67POtfNM8C1Fl6SDiuXE7c5JqDp3WtGM65GhC0KyScC1DNv8WHpfS56VgLzhnh yWeA== X-Gm-Message-State: AOJu0YwtYT6zVd71YbRcTDF+eAwYOFL0fJYCRyTJGE4wi0YH1KLMaRWN yjPmozbJvia0D69qqA/KgffhjnHfFIC7jxk6qb0Qp2SyN0zez77dqcgWx1SQbkc= X-Google-Smtp-Source: AGHT+IE5TpMHXsDsjiL0icD/RMD5WavdE5K8XnsZOmcb05w2J3fJkJger4TV74dwIWXK1ZdSbJOARw== X-Received: by 2002:a05:600c:4f09:b0:412:ae70:992e with SMTP id l9-20020a05600c4f0900b00412ae70992emr1077728wmq.21.1709036974728; Tue, 27 Feb 2024 04:29:34 -0800 (PST) Received: from ?IPV6:2001:16b8:2aaa:b100:c567:5d7d:c7b8:4efc? (200116b82aaab100c5675d7dc7b84efc.dip.versatel-1u1.de. [2001:16b8:2aaa:b100:c567:5d7d:c7b8:4efc]) by smtp.gmail.com with ESMTPSA id p37-20020a05600c1da500b00412b011458fsm537581wms.30.2024.02.27.04.29.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Feb 2024 04:29:34 -0800 (PST) Message-ID: Date: Tue, 27 Feb 2024 13:29:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch] OpenACC: Add Fortran routines acc_{alloc,free,hostptr,deviceptr,memcpy_{to,from}_device*} Content-Language: en-US To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org References: <3ef24b00-7ce1-43df-a62e-2817b2700fb9@baylibre.com> <87y1b66tqr.fsf@euler.schwinge.ddns.net> From: Tobias Burnus In-Reply-To: <87y1b66tqr.fsf@euler.schwinge.ddns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Thomas, (Regarding 'call acc_attach(x)' – the problem is that one needs the address of '&x' and 'x'; while 'x' is readily available, for '&x' no temporary variable has to get involved – and there are plenty of ways temporaries can get introduced; for most cases, an interface exists that prevents this but they are mutually exclusive. Hence, this needs support in the FE. The simplest workaround for a user is to use '!$acc attach' instead ...) Thomas Schwinge: >> @table @asis >> @item @emph{Description} >> -This function allocates @var{len} bytes of device memory. It returns >> +This function allocates @var{bytes} of device memory. It returns > Not '@var{bytes} {+bytes+}' or similar? I think either works – depending how one parses @var{} mentally, one of the variants sounds smooth and the other very odd. But I can/will change it. >> --- a/libgomp/openacc.f90 >> +++ b/libgomp/openacc.f90 > Assuming that 'module openacc_internal' currently is sorted per > appearance in the OpenACC specification (?), I suggest we continue to do > so. (..., like in 'openacc_lib.h', too.) I will check – it looks only block-wise sorted but I might be wrong.I followed location of the comments, placing it before the routines that followed the comment, assuming that the comments were at the right spot. >> @@ -794,6 +881,9 @@ module openacc >> ... >> + public :: acc_malloc, acc_free, acc_map_data, acc_unmap_data, acc_deviceptr >> + public :: acc_hostptr, acc_memcpy_to_device, acc_memcpy_to_device_async >> + public :: acc_memcpy_from_device, acc_memcpy_from_device_async >> ... >> - ! acc_malloc: Only available in C/C++ >> - ! acc_free: Only available in C/C++ >> - >> ... >> interface acc_is_present >> procedure :: acc_is_present_32_h >> procedure :: acc_is_present_64_h >> procedure :: acc_is_present_array_h >> end interface > Is that now a different style that we're not listing the new interfaces > in 'module openacc' here? As there is no precedent for this type of interface, the style is by nature differently. But the question is which style is better. The current 'openacc' is very short – and contains not a single specific interface, but only generic interfaces. The actual specific-procedure declarations are only in 'openacc_internal'. Those new procedures are the first ones that do not have a generic interface and only a specific one. Thus, one can either put the specific one into 'openacc_internal' and refer it from 'openacc' (via 'use openacc_internal' + 'public :: acc_') – or place the interface directly into 'openacc' (and not touching 'openacc_internal' at all). During development, I had a accidentally a mixture between both - and then settled for the current variant. – Possibly, moving the interface to 'openacc' is clearer? Thoughts? >> --- /dev/null >> +++ b/libgomp/testsuite/libgomp.fortran/acc_host_device_ptr.f90 >> [...] >> +! Fortran version of libgomp.oacc-c-c++-common/lib-59.c > I like to also put a cross reference into the originating C/C++ test > case, so that anyone adjusting either one also is aware that another one > may need adjusting, too. OK - I will do so. >> + ! The following assumes sizeof(void*) being the same on host and device: > That's generally required anyway. I have to admit that I don't know OpenACC well enough to see whether that's the case or not. And, while I am not very consistent, I do try to document stricter requirements / implementation-specific parts in a testcases. I know that OpenMP permits that the pointer size differs and 'void *p = omp_target_alloc (...);' might in this case not return the device pointer but a handle to the device ptr. (For instance, it could be a pointer to an uint128_t variable for a 128bit device pointer; I think such a hardware exists in real - and uses several bits for other purposes like flags.) In that case, host-side pointer arithmetic won't work and 'is_device_ptr' clauses etc. need to do transfer work. But, admittedly, in GCC there it is assumed at many places that both sides use the same pointer size* and also during specification development, everyone implicitly assumes that routines and clauses yield bare device pointers and not some opaque pointer to the actual data (a handle); hence, one has to keep remind oneself that the spec permits system where that's not the case. Tobias (* There are a few spots which handle a smaller device pointer than the host pointer or consider a different size but that's not done very consistently and largely lacking.)