[PATCH] D21853: [Driver][OpenMP] Update actions builder to create unbundling action when necessary.

Samuel Antao via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 25 11:13:24 PDT 2016


sfantao marked 7 inline comments as done.
sfantao added a comment.

Hi Hal,

Thanks for the review! Comments inlined.



================
Comment at: include/clang/Driver/Action.h:504
+  /// unbundling action.
+  struct DependingActionInfoTy final {
+    /// \brief The tool chain of the depending action.
----------------
hfinkel wrote:
> Don't need 'Ty' in the name of this struct.
Ok, using `DependentActionInfo` now.


================
Comment at: lib/Driver/Driver.cpp:2091
+        InputArg->getOption().getKind() == llvm::opt::Option::InputClass &&
+        !types::isSrcFile(HostAction->getType())) {
+      auto UnbundlingHostAction =
----------------
hfinkel wrote:
> hfinkel wrote:
> > This checks that the file needs to be preprocessed. What does preprocessing have to do with this? I don't imagine that providing a preprocessed source file as input should invoke the unbundler   .
> On second thought, this is okay. It does not make sense to have a non-bundled preprocessed source for the input there, as the host and device compilation don't share a common preprocessor state.
> 
> We do need to be careful, perhaps, about .s files (which don't need preprocessing as .S files do) -- we should probably assume that all non-bundled .s files are host assembly code.
Yes, that is what we do. If the bundler tool detects that the input is not a bundle, it assumes it is host code/bits. In either case, we still generate the unbundling tool as the driver doesn't check the contents of the files.


================
Comment at: test/Driver/openmp-offload.c:274
+/// Check separate compilation with offloading - unbundling actions
+// RUN:   touch %t.i
+// RUN:   %clang -### -ccc-print-phases -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i 2>&1 \
----------------
hfinkel wrote:
> hfinkel wrote:
> > Oh, are you using .i to indicate a bundle instead of a preprocessed file? Don't do that. Please use a different suffix -- the bundler has its own file format.
> Never mind; this is okay too.
Ok, there is no particular suffix to indicate a file is a bundle. The (un)bundler, however, has the machinery to detect if a given file is a bundle, it just uses the extension to understand if it is a human readable file, bitcode file, or object file, because the bundle format is different in those three cases.


https://reviews.llvm.org/D21853





More information about the cfe-commits mailing list