grokos marked 2 inline comments as done.
grokos added a comment.

In D74262#1867245 <https://reviews.llvm.org/D74262#1867245>, @ABataev wrote:

> Partial linking may lead to some incorrect results with global constructors. 
> How are you going to handle this?


Can you give me an example of what can break? I remember reading a conversation 
about some linker patch some time ago but I cannot recall the details.



================
Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:84
                        "  o   - object\n"
+                       "  oo  - object; output file is a list of unbundled 
objects\n"
                        "  gch - precompiled-header\n"
----------------
jdoerfert wrote:
> ABataev wrote:
> > Hmm, are you going to introduce a new kind of output? It really requires 
> > RFC.
> This is the offload-bundler tool, right? Who is using that except OpenMP (and 
> SYCL)?
> 
> Is there a reason for `oo`? `uo` (=unboundled object), or `do` (=device 
> object)?
No one else (at least for now). But I can send out an RFC regarding the new 
output anyway.

`oo` is related to the fact that under this scheme we can have multiple `.o` 
files as output (many `o`'s). But if you think some of the other abbreviations 
makes more sense, I'm happy to change it.


================
Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:160
+  }
+
   /// Write the header of the bundled file to \a OS based on the information
----------------
jdoerfert wrote:
> I don't understand the comment. If \p FileName is a list of outputs, how does 
> this work?
The scheme is described in the attached pdf. In short, when the host liner 
fetches dependencies from a static library, alongside the host bundle it also 
fetches the device bundle. Now, if we have multiple dependencies from multiple 
objects inside a static library (or multiple static libraries) the host linker 
will perform a partial linking between all fetched bundles for the targets we 
are interested in. The result is a fat object in which each target bundle is 
the result of concatenating the individual bundles for that target we fetched 
from each static library. We also keep track of the size of each fetched bundle 
(we use a new sizes section per target inside the fat object for this purpose) 
so that the unbundler can separate the partially-linked bundle into the 
original object files it was assembled from. Usually, we don't know a priori 
how many dependencies will be brought in, so we don't know how many objects 
we're going to have at outputs. Therefore, in `oo` unbundling mode, the user 
specifies a single output file per target (just like in any other unbundling 
mode) which the unbundler populates with the paths to the actual output device 
objects. Then the driver reads those paths and passes them on to the device 
linker.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74262



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to