[Openmp-dev] RFC. Moving functions out of headers to fix circular includes.

[Rokos, Georgios via Openmp-dev]

I second that. Headers that work only with a special include order is not the way to go and circular dependencies between them must be avoided.

FYI, Jon has uploaded a first patch for the proposed change here: https://reviews.llvm.org/D69489

Please have a look and comment if there are any concerns about this scheme.

Cheers,
George

-----Original Message-----
From: Openmp-dev <openmp-dev-bounces at lists.llvm.org> On Behalf Of Doerfert, Johannes via Openmp-dev
Sent: Monday, 28 October, 2019 14:08
To: Jon Chesterfield <jchesteramd at gmail.com>
Cc: via Openmp-dev <openmp-dev at lists.llvm.org>
Subject: Re: [Openmp-dev] RFC. Moving functions out of headers to fix circular includes.

I'm in favor.

Regardless of potential (current) nvcc shortcomings, especially because we can find ways around them (as you noted).

Thanks,
  Johannes


On 10/27, Jon Chesterfield via Openmp-dev wrote:
> Hey,
> 
> The deviceRTL dependency graph is not great. TLDR: I want to use a 
> unity build to work around nvcc lacking LTO so that we don't have to 
> write everything in circularly referenced headers.
> 
> omptarget-nvptx uses symbols from support and supporti uses symbols 
> from omptarget-nvptx. This currently works as supporti is included at 
> the end of omptarget-nvptx and everything includes omptarget-nvptx, 
> but it means that support.h doesn't work if you include it anywhere else.
> 
> This is sad because support.h declares an API that wraps builtin cuda 
> variables which would be really useful, except that I can't use it in 
> debug.h because all headers use debug, including omptarget-nvptx.
> 
> The root problem is that everything includes omptarget-nvptx and most 
> stuff is implemented inline in headers, quite a lot of which is then 
> used by omptarget-nvptx. Related hazards are some missing include 
> guards and headers that don't work unless they're included in a 
> specific order relative to each other.
> 
> I can cut through this tangle if we agree that moving functions out of 
> headers is fair game. amdgcn inlines everything anyway so we lose no 
> optimisation. The clang build of nvptx deviceRTL can do likewise. 
> It'll also make target_impl substantially more readable as I can put 
> the function declarations under a common directory and link in implementations.
> 
> The internet suggests that nvcc is not capable of cross translation 
> unit optimisations. Newer versions may be, it's difficult to search 
> for. I suggest we #include all the source into a single TU and build 
> that when using nvcc, game dev style.
> 
> Jon

> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev


-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov