[Openmp-commits] [PATCH] D70131: [libomptarget] Move supporti.h to support.cu

Wed Nov 13 03:29:12 PST 2019

JonChesterfield added a comment.

In D70131#1743165 <https://reviews.llvm.org/D70131#1743165>, @jdoerfert wrote:

> Arguably, we need to look into issues like "not inlined" in device compilation separately and more generically. Marking all runtime functions always_inline but not the user code is less helpful than adjusting the inline threshold based on the target.

I'd go further. "inlined" can also be an issue, either where it produces N copies of a slow function (e.g. printf) where there should be one or where it thrashes the instruction cache. Beyond the scope of this patch, but agreed that it's a task.

In D70131#1743165 <https://reviews.llvm.org/D70131#1743165>, @jdoerfert wrote:

> > We don't have any bitcode library level optimisations at present. I'd like to internalise the non-api symbols and run opt across it during the build. That's essentially a build time optimisation for the clients of the library and orthogonal to this change.
>
> I'm unsure what you mean in the first part. Internalizing symbols and aggressively removing unneeded part of the device runtime is for sure what we want to do, maybe even for api symbols.

The nvptx deviceRTL is N individually optimised bitcode files combined with llvm-link. Anything `opt -O2` or similar would do to optimise across the previously separate files will be repeated for every application at application compile time, whereas we could reasonably do it once before installing the bitcode library by invoking opt. This extra opt pass would probably change the code in the final executable in minor ways, but the motivation is link time reduction for the application code.

Symbol internalizing is great. Non-inlined functions can have bespoke calling conventions, symbols in application code can no longer collide with those in the library, dead stuff can be discarded. We have a bitcode support library that can probably be merged into deviceRTL and then itself entirely internalised. Loads of good options from postponing machine code generation.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70131/new/

https://reviews.llvm.org/D70131