关于目标构造限制的ARB问题

Question

在一个研究项目中，我们正在开发一种特殊用途的浮点加速器.在此背景下，我们最初的设想是从ARM主机-> RISCV管理的加速器集群->中获得一种“两级”或“嵌套”卸载，即实际的浮点加速器。

因此，我们希望实现类似于以下代码的目标：

// start on ARM host
#pragma omp target
{
  // we are on RISCV
  #pragma omp target
  {
    // we are on the floating-point accelerator
    ...do math
  }
}

在最新的OpenMP 5.2API规范中，我在"13.8目标构造->限制“下面找到了该段

“在目标区域的执行过程中，不能遇到设备影响结构，但指定了祖先设备修饰符的目标构造除外。”

据我所见，这在OpenMP 5.2中是新的，并且似乎明确禁止嵌套卸载的概念。我们很有兴趣去理解

-if我们正确地理解了这一点，即现在明确禁止嵌套卸载，而不是像以前5.1API规范那样“未指定”。

-if嵌套卸载是被禁止的，是什么设计决定导致这一点的ARB？

-if是否有可能在OpenMP的未来API规范中加入一种嵌套卸载规范，以支持异构加速器之间嵌套卸载的场景？

我会非常感谢你的回答！

诚挚的问候,

凯·普洛西尼

Answer 1

这需要一些上下文才能正确地回答。在OpenMP规范中，当我们有这样的规则时，它意味着结果是“未指定的行为”。在这种情况下，通常预期的行为是，实现将发出诊断，因此是“必须”，但是如果给定的供应商决定他们希望提供的行为是嵌套的构造工作，那么就规范而言，这是完全可以的。这只意味着程序不会移植到其他实现中。

在此背景下：

-if我们正确地理解了这一点，即现在明确禁止嵌套卸载，而不是像上一个5.1API规范那样“未指定”。

目标区域从未完全支持target构造。您最初回避的限制是4.0中的以下内容：

If a target, target update, or target data construct appears within a target
region then the behavior is unspecified.

两者的效果是一样的。

-if嵌套卸载是被禁止的，是什么设计决定导致这一点的ARB？

因为我们支持device(ancestor)子句以允许反向卸载，这比以前更少禁止。其目的是研究支持完全嵌套卸载，但在使该可移植性方面存在很大的复杂性。有些实现可以同时支持卸载到同一设备，有些不能，其他实现可以很容易地支持将其卸载到同级设备，其他实现则不能。因此，就规范而言，目前我们继续不支持它。

-if是否有可能在未来OpenMP的API规范中加入一种嵌套卸载规范，以支持异构加速器之间嵌套卸载的场景？

这是绝对有可能的，事实上我们已经有了一个最小的版本，而且我可以想到至少有一个研究实现可以做到这一点。真正的障碍是获得一个可移植的接口。最微小的改变可能会使这种行为被接受，比如添加一个requires子句来支持嵌套卸载，但是即使在那里，我们也必须回答很多关于这种行为的问题。

如果你有兴趣建立这样的支持，我们总是寻找有动力的人来推动这样的努力。如果您想要更多的信息，请随时与我联系。