[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGddeab07ca632: [clang-repl][CUDA] Re-land: Initial 
interactive CUDA support for clang-repl (authored by argentite).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/DeviceOffload.cpp
  clang/lib/Interpreter/DeviceOffload.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/Interpreter/CUDA/device-function-template.cu
  clang/test/Interpreter/CUDA/device-function.cu
  clang/test/Interpreter/CUDA/host-and-device.cu
  clang/test/Interpreter/CUDA/lit.local.cfg
  clang/test/Interpreter/CUDA/memory.cu
  clang/test/Interpreter/CUDA/sanity.cu
  clang/test/lit.cfg.py
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -46,7 +46,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -38,7 +38,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -20,9 +20,13 @@
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/ManagedStatic.h" // llvm_shutdown
 #include "llvm/Support/Signals.h"
-#include "llvm/Support/TargetSelect.h" // llvm::Initialize*
+#include "llvm/Support/TargetSelect.h"
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -76,8 +80,11 @@
   std::vector ClangArgv(ClangArgs.size());
   std::transform(ClangArgs.begin(), ClangArgs.end(), ClangArgv.begin(),
  [](const std::string ) -> const char * { return s.data(); });
-  llvm::InitializeNativeTarget();
-  llvm::InitializeNativeTargetAsmPrinter();
+  // Initialize all targets (required for device offloading)
+  llvm::InitializeAllTargetInfos();
+  llvm::InitializeAllTargets();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmPrinters();
 
   if (OptHostSupportsJit) {
 auto J = 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite updated this revision to Diff 525572.
argentite added a comment.

Workaround for depending on NVPTX symbols: initialize all available targets 
instead. If NVPTX is not available, it will complain when we try to actually 
execute anything in CUDA mode.
Rebased and fixed conflicts on recent value printing related patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/DeviceOffload.cpp
  clang/lib/Interpreter/DeviceOffload.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/Interpreter/CUDA/device-function-template.cu
  clang/test/Interpreter/CUDA/device-function.cu
  clang/test/Interpreter/CUDA/host-and-device.cu
  clang/test/Interpreter/CUDA/lit.local.cfg
  clang/test/Interpreter/CUDA/memory.cu
  clang/test/Interpreter/CUDA/sanity.cu
  clang/test/lit.cfg.py
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -46,7 +46,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -38,7 +38,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -20,9 +20,13 @@
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/ManagedStatic.h" // llvm_shutdown
 #include "llvm/Support/Signals.h"
-#include "llvm/Support/TargetSelect.h" // llvm::Initialize*
+#include "llvm/Support/TargetSelect.h"
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -76,8 +80,11 @@
   std::vector ClangArgv(ClangArgs.size());
   std::transform(ClangArgs.begin(), ClangArgs.end(), ClangArgv.begin(),
  [](const std::string ) -> const char * { return s.data(); });
-  llvm::InitializeNativeTarget();
-  llvm::InitializeNativeTargetAsmPrinter();
+  // Initialize all targets (required for device offloading)
+  llvm::InitializeAllTargetInfos();
+  llvm::InitializeAllTargets();
+  

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D146389#4358358 , @argentite wrote:

> Added some std::move fixes for Error -> Expected conversions
>
> We need to figure out a solution when NVPTX backend is not enabled. 
> clang-repl probably should not depends on that. Example: 
> https://lab.llvm.org/buildbot#builders/175/builds/29764

We can do `Triple::isNVPTX` and then initialize the asm printer. @lhames could 
have better idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite updated this revision to Diff 524006.
argentite added a comment.

Added some std::move fixes for Error -> Expected conversions

We need to figure out a solution when NVPTX backend is not enabled. clang-repl 
probably should not depends on that. Example: 
https://lab.llvm.org/buildbot#builders/175/builds/29764


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/DeviceOffload.cpp
  clang/lib/Interpreter/DeviceOffload.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/Interpreter/CUDA/device-function-template.cu
  clang/test/Interpreter/CUDA/device-function.cu
  clang/test/Interpreter/CUDA/host-and-device.cu
  clang/test/Interpreter/CUDA/lit.local.cfg
  clang/test/Interpreter/CUDA/memory.cu
  clang/test/Interpreter/CUDA/sanity.cu
  clang/test/lit.cfg.py
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -40,7 +40,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -38,7 +38,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,10 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +94,36 @@
 return 0;
   }
 
+  clang::IncrementalCompilerBuilder CB;
+  CB.SetCompilerArgs(ClangArgv);
+
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+if (!CudaPath.empty())
+  CB.SetCudaSDK(CudaPath);
+
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+CB.SetOffloadArch(OffloadArch);
+
+DeviceCI = ExitOnErr(CB.CreateCudaDevice());
+  }
+
   // FIXME: Investigate if we could use 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG80e7eed6a610: [clang-repl][CUDA] Initial interactive CUDA 
support for clang-repl (authored by argentite).

Changed prior to commit:
  https://reviews.llvm.org/D146389?vs=522717=524000#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/DeviceOffload.cpp
  clang/lib/Interpreter/DeviceOffload.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/Interpreter/CUDA/device-function-template.cu
  clang/test/Interpreter/CUDA/device-function.cu
  clang/test/Interpreter/CUDA/host-and-device.cu
  clang/test/Interpreter/CUDA/lit.local.cfg
  clang/test/Interpreter/CUDA/memory.cu
  clang/test/Interpreter/CUDA/sanity.cu
  clang/test/lit.cfg.py
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -40,7 +40,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -38,7 +38,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,10 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +94,36 @@
 return 0;
   }
 
+  clang::IncrementalCompilerBuilder CB;
+  CB.SetCompilerArgs(ClangArgv);
+
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+if (!CudaPath.empty())
+  CB.SetCudaSDK(CudaPath);
+
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+CB.SetOffloadArch(OffloadArch);
+
+DeviceCI = ExitOnErr(CB.CreateCudaDevice());
+  }
+
   // FIXME: Investigate if we could use 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev accepted this revision.
v.g.vassilev added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite updated this revision to Diff 522717.
argentite added a comment.

Update the filenames


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/DeviceOffload.cpp
  clang/lib/Interpreter/DeviceOffload.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/Interpreter/CUDA/device-function-template.cu
  clang/test/Interpreter/CUDA/device-function.cu
  clang/test/Interpreter/CUDA/host-and-device.cu
  clang/test/Interpreter/CUDA/lit.local.cfg
  clang/test/Interpreter/CUDA/memory.cu
  clang/test/Interpreter/CUDA/sanity.cu
  clang/test/lit.cfg.py
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -40,7 +40,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -38,7 +38,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,10 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +94,36 @@
 return 0;
   }
 
+  clang::IncrementalCompilerBuilder CB;
+  CB.SetCompilerArgs(ClangArgv);
+
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+if (!CudaPath.empty())
+  CB.SetCudaSDK(CudaPath);
+
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+CB.SetOffloadArch(OffloadArch);
+
+DeviceCI = ExitOnErr(CB.CreateCudaDevice());
+  }
+
   // FIXME: Investigate if we could use runToolOnCodeWithArgs from tooling. It
   // can replace the boilerplate code for creation of the compiler instance.
-  auto CI = ExitOnErr(clang::IncrementalCompilerBuilder::create(ClangArgv));
+  std::unique_ptr CI;
+  if (CudaEnabled) {
+

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

This is looking good. Can you address my minor comments and run clang-format?




Comment at: clang/lib/Interpreter/DeviceOffload.cpp:1
+//===-- Offload.cpp - CUDA Offloading ---*- C++ 
-*-===//
+//

v.g.vassilev wrote:
> Likewise.
ping.



Comment at: clang/lib/Interpreter/DeviceOffload.h:1
+//===-- Offload.h - Device Offloading ---*- C++ 
-*-===//
+//

We should rename `Offload.h` to `DeviceOffload.h`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite updated this revision to Diff 522041.
argentite added a comment.

Remove the copy of CodeGenOpts in CodeGeneratorImpl


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/DeviceOffload.cpp
  clang/lib/Interpreter/DeviceOffload.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/Interpreter/CUDA/device-function-template.cu
  clang/test/Interpreter/CUDA/device-function.cu
  clang/test/Interpreter/CUDA/host-and-device.cu
  clang/test/Interpreter/CUDA/lit.local.cfg
  clang/test/Interpreter/CUDA/memory.cu
  clang/test/Interpreter/CUDA/sanity.cu
  clang/test/lit.cfg.py
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -40,7 +40,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -38,7 +38,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,10 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +94,36 @@
 return 0;
   }
 
+  clang::IncrementalCompilerBuilder CB;
+  CB.SetCompilerArgs(ClangArgv);
+
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+if (!CudaPath.empty())
+  CB.SetCudaSDK(CudaPath);
+
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+CB.SetOffloadArch(OffloadArch);
+
+DeviceCI = ExitOnErr(CB.CreateCudaDevice());
+  }
+
   // FIXME: Investigate if we could use runToolOnCodeWithArgs from tooling. It
   // can replace the boilerplate code for creation of the compiler instance.
-  auto CI = ExitOnErr(clang::IncrementalCompilerBuilder::create(ClangArgv));
+  std::unique_ptr 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: clang/lib/CodeGen/ModuleBuilder.cpp:39
 const PreprocessorOptions  // Only used for debug info.
-const CodeGenOptions CodeGenOpts;  // Intentionally copied in.
+CodeGenOptions CodeGenOpts;  // Intentionally copied in.
 

argentite wrote:
> v.g.vassilev wrote:
> > IIUC history correctly, here the intentional copy was to prevent some 
> > layering violation for what was called in 2009 `CompileOpts`. I believe 
> > that is not the case, can you check if we can take a const reference here? 
> I don't understand how the reference causes layering violation but if I 
> change it to a const reference instead, the option modification code becomes 
> slightly less awkward and all tests seem to be fine.
Let's try that then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite added inline comments.



Comment at: clang/lib/CodeGen/ModuleBuilder.cpp:39
 const PreprocessorOptions  // Only used for debug info.
-const CodeGenOptions CodeGenOpts;  // Intentionally copied in.
+CodeGenOptions CodeGenOpts;  // Intentionally copied in.
 

v.g.vassilev wrote:
> IIUC history correctly, here the intentional copy was to prevent some 
> layering violation for what was called in 2009 `CompileOpts`. I believe that 
> is not the case, can you check if we can take a const reference here? 
I don't understand how the reference causes layering violation but if I change 
it to a const reference instead, the option modification code becomes slightly 
less awkward and all tests seem to be fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: clang/lib/CodeGen/ModuleBuilder.cpp:39
 const PreprocessorOptions  // Only used for debug info.
-const CodeGenOptions CodeGenOpts;  // Intentionally copied in.
+CodeGenOptions CodeGenOpts;  // Intentionally copied in.
 

IIUC history correctly, here the intentional copy was to prevent some layering 
violation for what was called in 2009 `CompileOpts`. I believe that is not the 
case, can you check if we can take a const reference here? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite updated this revision to Diff 521742.
argentite marked an inline comment as done.
argentite added a comment.

Add some CUDA basic functionality tests.
Disallow undo-ing of the initial PTU. This should fix the undo command test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/CodeGen/ModuleBuilder.h
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/DeviceOffload.cpp
  clang/lib/Interpreter/DeviceOffload.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/Interpreter/CUDA/device-function-template.cu
  clang/test/Interpreter/CUDA/device-function.cu
  clang/test/Interpreter/CUDA/host-and-device.cu
  clang/test/Interpreter/CUDA/lit.local.cfg
  clang/test/Interpreter/CUDA/memory.cu
  clang/test/Interpreter/CUDA/sanity.cu
  clang/test/lit.cfg.py
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -40,7 +40,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -38,7 +38,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,10 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +94,36 @@
 return 0;
   }
 
+  clang::IncrementalCompilerBuilder CB;
+  CB.SetCompilerArgs(ClangArgv);
+
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+if (!CudaPath.empty())
+  CB.SetCudaSDK(CudaPath);
+
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+CB.SetOffloadArch(OffloadArch);
+
+DeviceCI = ExitOnErr(CB.CreateCudaDevice());
+  }
+
   // FIXME: Investigate if we could use runToolOnCodeWithArgs from tooling. It
   // can replace 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

Generally lgtm, let's extend the test coverage.




Comment at: clang/lib/Interpreter/DeviceOffload.cpp:1
+//===-- Offload.cpp - CUDA Offloading ---*- C++ 
-*-===//
+//

Likewise.



Comment at: clang/lib/Interpreter/DeviceOffload.h:1
+//===--- Offload.h - CUDA Offloading *- C++ 
-*-===//
+//

We should probably update the name here as well and maybe drop CUDA?



Comment at: clang/test/Interpreter/CUDA/sanity.cu:10
+// CHECK: CUDA Error: 0
+
+%quit

Let's extend the coverage with some more standard hello world examples. We can 
draw some inspiration from 
https://github.com/root-project/cling/tree/master/test/CUDADeviceCode


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite updated this revision to Diff 520636.
argentite marked 3 inline comments as done.
argentite added a comment.

Added a check to run CUDA tests only on systems with CUDA. We need some ideas 
for the actual tests.
Rename Offload.cpp to DeviceOffload.cpp
Other syntax/style fixes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/CodeGen/ModuleBuilder.h
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/DeviceOffload.cpp
  clang/lib/Interpreter/DeviceOffload.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/Interpreter/CUDA/lit.local.cfg
  clang/test/Interpreter/CUDA/sanity.cu
  clang/test/lit.cfg.py
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -40,7 +40,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -21,6 +21,7 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
+#include "llvm-c/Error.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ExecutionEngine/Orc/LLJIT.h"
 #include "llvm/Support/ManagedStatic.h"
@@ -38,7 +39,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,10 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +94,36 @@
 return 0;
   }
 
+  clang::IncrementalCompilerBuilder CB;
+  CB.SetCompilerArgs(ClangArgv);
+
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+if (!CudaPath.empty())
+  CB.SetCudaSDK(CudaPath);
+
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+CB.SetOffloadArch(OffloadArch);
+
+DeviceCI = 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: clang/lib/Interpreter/Interpreter.cpp:144-146
   ClangArgv.insert(ClangArgv.end(), "-Xclang");
   ClangArgv.insert(ClangArgv.end(), "-fincremental-extensions");
   ClangArgv.insert(ClangArgv.end(), "-c");

Hahnfeld wrote:
> This doesn't do what the comments claim - it appends at the end, not 
> prepends. For that it would need to be `ClangArgv.insert(ClangArgv.begin(), 
> "-c")`. @v.g.vassilev what do we want here? (probably doesn't block this 
> revision, but it's odd nevertheless)
Yeah, this forces the clang::Driver to have some sort of action. In turn, this 
helps produce diagnostics from the driver before failing. That's a known bug 
since the early days of clang that nobody addressed... 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

Some comments, but otherwise LGTM




Comment at: clang/include/clang/Interpreter/Interpreter.h:43
 public:
+  IncrementalCompilerBuilder(){};
+

and this should probably be run through `clang-format`...



Comment at: clang/include/clang/Interpreter/Interpreter.h:45
+
+  void SetCompilerArgs(const std::vector Args) {
+UserArgs = Args;





Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6257
+  // Device code should not be at top level.
+  if (LangOpts.CUDA && LangOpts.CUDAIsDevice)
+return;

tra wrote:
> Could you give me an example of what exactly we'll be skipping here?
> Will it affect `__device__` variables? 
> 
This concerns statements at the global scope that only concern the REPL; see 
https://reviews.llvm.org/D127284 for the original revision. Global variables on 
the other hand are passed via `EmitTopLevelDecl` -> `EmitGlobal`.



Comment at: clang/lib/Interpreter/Interpreter.cpp:143
   // FIXME: Print proper driver diagnostics if the driver flags are wrong.
   // We do C++ by default; append right after argv[0] if no "-x" given
   ClangArgv.insert(ClangArgv.end(), "-Xclang");

This comment should move as well



Comment at: clang/lib/Interpreter/Interpreter.cpp:144-146
   ClangArgv.insert(ClangArgv.end(), "-Xclang");
   ClangArgv.insert(ClangArgv.end(), "-fincremental-extensions");
   ClangArgv.insert(ClangArgv.end(), "-c");

This doesn't do what the comments claim - it appends at the end, not prepends. 
For that it would need to be `ClangArgv.insert(ClangArgv.begin(), "-c")`. 
@v.g.vassilev what do we want here? (probably doesn't block this revision, but 
it's odd nevertheless)



Comment at: clang/lib/Interpreter/Offload.h:36-37
+
+  // Write last PTX to the fatbinary file
+  // llvm::Error WriteFatbinary() const;
+

unused


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Simeon Ehrig via Phabricator via cfe-commits]

SimeonEhrig added a comment.

In D146389#4292984 , @tra wrote:

> lib/CodeGen changes look OK to me.

I can confirm the code change in CodeGen works as expected. `clang-repl` does 
not generate temporary files anymore, if a CUDA kernel is compiled.

Compiling a simple CUDA application still working and saving the generated PTX 
and fatbin code via `clang++ ../helloWorld.cu -o helloWorld 
-L/usr/local/cuda/lib64 -lcudart_static --save-temps` is also still working.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

lib/CodeGen changes look OK to me.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6257
+  // Device code should not be at top level.
+  if (LangOpts.CUDA && LangOpts.CUDAIsDevice)
+return;

Could you give me an example of what exactly we'll be skipping here?
Will it affect `__device__` variables? 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite added inline comments.



Comment at: clang/lib/Interpreter/Offload.cpp:1
+//===-- Offload.cpp - CUDA Offloading ---*- C++ 
-*-===//
+//

v.g.vassilev wrote:
> argentite wrote:
> > Hahnfeld wrote:
> > > v.g.vassilev wrote:
> > > > How about `DeviceOffload.cpp`?
> > > Or `IncrementalCUDADeviceParser.cpp` for the moment - not sure what other 
> > > classes will be added in the future, and if they should be in the same TU.
> > I wanted to avoid "CUDA" in case we use it later for HIP.
> Was `DeviceOffload.cpp` not a better name for the file and its intent?
Yeah that seems alright, I will change in the next revision.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

Generally, looks good to me. I'd like to wait for @Hahnfeld and @tra's feedback 
at least for another week before merging.

@dblaikie, I know that generally we do not want to run tests on the bots and 
that makes testing quite hard for this patch. Do you have a suggestion how to 
move forward here? In principle, we could have another option where we might 
has the JIT if it can execute code on the device if available.




Comment at: clang/lib/Interpreter/Offload.cpp:1
+//===-- Offload.cpp - CUDA Offloading ---*- C++ 
-*-===//
+//

argentite wrote:
> Hahnfeld wrote:
> > v.g.vassilev wrote:
> > > How about `DeviceOffload.cpp`?
> > Or `IncrementalCUDADeviceParser.cpp` for the moment - not sure what other 
> > classes will be added in the future, and if they should be in the same TU.
> I wanted to avoid "CUDA" in case we use it later for HIP.
Was `DeviceOffload.cpp` not a better name for the file and its intent?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite updated this revision to Diff 516061.
argentite added a comment.
Herald added a subscriber: ormris.

Use virtual file system to store CUDA fatbinaries in memory
Adapted Interpreter tests to use the CompilerBuilder


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/CodeGen/ModuleBuilder.h
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/lib/Interpreter/Offload.cpp
  clang/lib/Interpreter/Offload.h
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -40,7 +40,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/unittests/Interpreter/IncrementalProcessingTest.cpp
===
--- clang/unittests/Interpreter/IncrementalProcessingTest.cpp
+++ clang/unittests/Interpreter/IncrementalProcessingTest.cpp
@@ -52,7 +52,9 @@
 
 TEST(IncrementalProcessing, EmitCXXGlobalInitFunc) {
   std::vector ClangArgv = {"-Xclang", "-emit-llvm-only"};
-  auto CI = llvm::cantFail(IncrementalCompilerBuilder::create(ClangArgv));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgv);
+  auto CI = cantFail(CB.CreateCpp());
   auto Interp = llvm::cantFail(Interpreter::create(std::move(CI)));
 
   std::array PTUs;
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -21,11 +21,11 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
+#include "llvm-c/Error.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ExecutionEngine/Orc/LLJIT.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/TargetSelect.h"
-#include "llvm-c/Error.h"
 
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -39,7 +39,9 @@
   DiagnosticConsumer *Client = nullptr) {
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
-  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  auto CB = clang::IncrementalCompilerBuilder();
+  CB.SetCompilerArgs(ClangArgs);
+  auto CI = cantFail(CB.CreateCpp());
   if (Client)
 CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,10 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +94,36 @@
 return 0;
   }
 
+  clang::IncrementalCompilerBuilder CB;
+  CB.SetCompilerArgs(ClangArgv);
+
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+if (!CudaPath.empty())
+  CB.SetCudaSDK(CudaPath);
+
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+CB.SetOffloadArch(OffloadArch);
+
+DeviceCI = ExitOnErr(CB.CreateCudaDevice());
+  }
+
   // FIXME: Investigate if we could use 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a reviewer: dblaikie.
v.g.vassilev added a subscriber: dblaikie.
v.g.vassilev added a comment.

I am adding @dblaikie as he might have ideas how to test this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite added inline comments.



Comment at: clang/lib/Interpreter/Offload.cpp:90-91
+  PTXCode += '\0';
+  while (PTXCode.size() % 8)
+PTXCode += '\0';
+  return PTXCode.str();

Hahnfeld wrote:
> Is padding to 8 bytes a requirement for PTX? Maybe add a coment...
This was actually in original Cling implementation but it does not seem to be 
required.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite updated this revision to Diff 512521.
argentite marked 3 inline comments as done.
argentite added a comment.

Combined IncrementalCompilerBuilder and IncrementalCudaCompilerBuilder
Added --cuda-path support
Use sys::fs::createTemporaryFile() instead of hardcoding the path
Other minor refactoring

I am planning to have the in-memory fat binary file as a separate patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/lib/Interpreter/Offload.cpp
  clang/lib/Interpreter/Offload.h
  clang/tools/clang-repl/ClangRepl.cpp

Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,10 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt CudaPath("cuda-path", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +94,40 @@
 return 0;
   }
 
+  clang::IncrementalCompilerBuilder CB;
+  CB.SetCompilerArgs(ClangArgv);
+
+  llvm::SmallString<128> CudaTempFile;
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+if (!CudaPath.empty())
+  CB.SetCudaSDK(CudaPath);
+
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+CB.SetOffloadArch(OffloadArch);
+
+llvm::sys::fs::createTemporaryFile("clang-repl", "fatbin", CudaTempFile);
+CB.SetCudaTempFatbinFile(CudaTempFile);
+
+DeviceCI = ExitOnErr(CB.CreateCudaDevice());
+  }
+
   // FIXME: Investigate if we could use runToolOnCodeWithArgs from tooling. It
   // can replace the boilerplate code for creation of the compiler instance.
-  auto CI = ExitOnErr(clang::IncrementalCompilerBuilder::create(ClangArgv));
+  std::unique_ptr CI;
+  if (CudaEnabled) {
+CI = ExitOnErr(CB.CreateCudaHost());
+  } else {
+CI = ExitOnErr(CB.CreateCpp());
+  }
 
   // Set an error handler, so that any LLVM backend diagnostics go through our
   // error handler.
@@ -101,8 +136,23 @@
 
   // Load any requested plugins.
   CI->LoadRequestedPlugins();
+  if (CudaEnabled)
+DeviceCI->LoadRequestedPlugins();
+
+  std::unique_ptr Interp;
+  if (CudaEnabled) {
+Interp = ExitOnErr(clang::Interpreter::createWithCUDA(
+std::move(CI), std::move(DeviceCI), CudaTempFile));
+
+if (CudaPath.empty()) {
+  ExitOnErr(Interp->LoadDynamicLibrary("libcudart.so"));
+} else {
+  auto CudaRuntimeLibPath = CudaPath + "/lib/libcudart.so";
+  ExitOnErr(Interp->LoadDynamicLibrary(CudaRuntimeLibPath.c_str()));
+}
+  } else
+Interp = ExitOnErr(clang::Interpreter::create(std::move(CI)));
 
-  auto Interp = ExitOnErr(clang::Interpreter::create(std::move(CI)));
   for (const std::string  : OptInputs) {
 if (auto Err = Interp->ParseAndExecute(input))
   llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "error: ");
@@ -138,6 +188,9 @@
 }
   }
 
+  if (!CudaTempFile.empty())
+llvm::sys::fs::remove(CudaTempFile);
+
   // Our error handler depends on the Diagnostics object, which we're
   // potentially about to delete. Uninstall the handler now so that any
   // later errors use the default handling behavior instead.
Index: clang/lib/Interpreter/Offload.h
===
--- /dev/null
+++ clang/lib/Interpreter/Offload.h
@@ -0,0 +1,46 @@
+//===--- Offload.h - CUDA Offloading *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements classes required for offloading to CUDA devices.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_INTERPRETER_OFFLOAD_H
+#define LLVM_CLANG_LIB_INTERPRETER_OFFLOAD_H
+
+#include "IncrementalParser.h"
+#include "llvm/Support/FileSystem.h"
+
+namespace clang {
+
+class IncrementalCUDADeviceParser : public IncrementalParser {
+public:
+  IncrementalCUDADeviceParser(std::unique_ptr 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Simeon Ehrig via Phabricator via cfe-commits]

SimeonEhrig added a comment.

Except using an in-memory solution for generated fatbin code, the code looks 
good to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added inline comments.



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:296
   }
+  LinkModules.clear();
   return false; // success

v.g.vassilev wrote:
> argentite wrote:
> > Hahnfeld wrote:
> > > This looks like a change that has implications beyond support for CUDA. 
> > > Would it make sense to break this out into a separate review, ie does 
> > > this change something in the current setup?
> > It actually was a separate patch: D146388 Should I submit that for review?
> > It seems to be required because we call `LinkInModules()` once for every 
> > interpreter iteration.
> > 
> The problem with going for a separate change is that we cannot test it. 
> Landing it without a test makes the history commit unclear. This patch (and 
> the tests we add here) will at least indirectly test that change.
Ok, that's why I was asking if it changes something in the current setup (ie 
can be tested). Thanks for clarifying.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:296
   }
+  LinkModules.clear();
   return false; // success

argentite wrote:
> Hahnfeld wrote:
> > This looks like a change that has implications beyond support for CUDA. 
> > Would it make sense to break this out into a separate review, ie does this 
> > change something in the current setup?
> It actually was a separate patch: D146388 Should I submit that for review?
> It seems to be required because we call `LinkInModules()` once for every 
> interpreter iteration.
> 
The problem with going for a separate change is that we cannot test it. Landing 
it without a test makes the history commit unclear. This patch (and the tests 
we add here) will at least indirectly test that change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite added a comment.

In D146389#4243900 , @tra wrote:

>> Initial interactive CUDA support for clang-repl
>
> What should a user expect to be supported, functionality wise? I assume it 
> should cover parsing and compilation. I'm not so sure about the execution. 
> Should it be expected to actually launch kernels, or will that come in a 
> future patch?

With this patch alone, we can launch kernels with the usual syntax. The 
`__device__` functions need to be `inline` for now. We plan to automate that in 
the future.




Comment at: clang/include/clang/Interpreter/Interpreter.h:43-44
 public:
   static llvm::Expected>
   create(std::vector );
+  static llvm::Expected>

Hahnfeld wrote:
> If I understand the change correctly, the "old" `create` function on its own 
> is not sufficient anymore to create a fully working `CompilerInstance` - 
> should we make it `private`? (and unify the two `Builder` classes into one?)
> 
> Alternatively, we could keep the current function working and move the bulk 
> of the work to an `createInternal` function. What do you think?
Yes the old `create` should probably be private. I was also thinking we could 
merge `IncrementalCudaCompilerBuilder` with `IncrementalCompilerBuilder` and 
make it stateful with CUDA SDK path for example. Then we could do something 
like:
```
IncrementalCompilerBuilder Builder;
Builder.setCudaPath(...);
auto DeviceCI = Builder.createCudaDevice();
auto HostCI = Builder.createCudaHost();
```



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:296
   }
+  LinkModules.clear();
   return false; // success

Hahnfeld wrote:
> This looks like a change that has implications beyond support for CUDA. Would 
> it make sense to break this out into a separate review, ie does this change 
> something in the current setup?
It actually was a separate patch: D146388 Should I submit that for review?
It seems to be required because we call `LinkInModules()` once for every 
interpreter iteration.




Comment at: clang/lib/Interpreter/IncrementalParser.cpp:125
 
+static CodeGenerator *getCodeGen(FrontendAction *Act);
+

Hahnfeld wrote:
> Is it possible to move the `static` function here instead of forward 
> declaring? Or does it depend on other functions in this file?
We can probably move this. I just wanted to preserve the history,



Comment at: clang/lib/Interpreter/IncrementalParser.cpp:143-156
+  // An initial PTU is needed as CUDA includes some headers automatically
+  auto PTU = ParseOrWrapTopLevelDecl();
+  if (auto E = PTU.takeError()) {
+consumeError(std::move(E)); // FIXME
+return; // PTU.takeError();
+  }
+

Hahnfeld wrote:
> Should this be done as part of the "generic" `IncrementalParser` constructor, 
> or only in the CUDA case by something else? Maybe 
> `Interpreter::createWithCUDA`?
That seems safer. Although I did not notice any side effects.



Comment at: clang/lib/Interpreter/Interpreter.cpp:270-274
+  if (DeviceParser) {
+auto DevicePTU = DeviceParser->Parse(Code);
+if (auto E = DevicePTU.takeError())
+  return E;
+  }

Hahnfeld wrote:
> Just wondering about the order here: Do we have to parse the device side 
> first? Does it make a difference for diagnostics? Maybe you can add a comment 
> about the choice here...
The fatbinary from the device side is used in the host pipeline.



Comment at: clang/lib/Interpreter/Offload.cpp:1
+//===-- Offload.cpp - CUDA Offloading ---*- C++ 
-*-===//
+//

Hahnfeld wrote:
> v.g.vassilev wrote:
> > How about `DeviceOffload.cpp`?
> Or `IncrementalCUDADeviceParser.cpp` for the moment - not sure what other 
> classes will be added in the future, and if they should be in the same TU.
I wanted to avoid "CUDA" in case we use it later for HIP.



Comment at: clang/tools/clang-repl/ClangRepl.cpp:137
+
+ExitOnErr(Interp->LoadDynamicLibrary("libcudart.so"));
+  } else

v.g.vassilev wrote:
> tra wrote:
> > v.g.vassilev wrote:
> > > tra wrote:
> > > > Is there any doc describing the big picture approach to CUDA REPL 
> > > > implementation and how all the pieces tie together?
> > > > 
> > > > From the patch I see that we will compile GPU side of the code to PTX, 
> > > > pack it into fatbinary, but it's not clear now do we get from there to 
> > > > actually launching the kernels. Loading libcudart.so here also does not 
> > > > appear to be tied to anything else. I do not see any direct API calls, 
> > > > and the host-side compilation appears to be done w.o passing the GPU 
> > > > binary to it, which would normally trigger generation of the glue code 
> > > > to register the kernels with CUDA runtime. I may be missing something, 
> > > > too.
> > > > 
> > > > I assume the 

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added inline comments.



Comment at: clang/include/clang/Interpreter/Interpreter.h:43-44
 public:
   static llvm::Expected>
   create(std::vector );
+  static llvm::Expected>

If I understand the change correctly, the "old" `create` function on its own is 
not sufficient anymore to create a fully working `CompilerInstance` - should we 
make it `private`? (and unify the two `Builder` classes into one?)

Alternatively, we could keep the current function working and move the bulk of 
the work to an `createInternal` function. What do you think?



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:296
   }
+  LinkModules.clear();
   return false; // success

This looks like a change that has implications beyond support for CUDA. Would 
it make sense to break this out into a separate review, ie does this change 
something in the current setup?



Comment at: clang/lib/Interpreter/IncrementalParser.cpp:125
 
+static CodeGenerator *getCodeGen(FrontendAction *Act);
+

Is it possible to move the `static` function here instead of forward declaring? 
Or does it depend on other functions in this file?



Comment at: clang/lib/Interpreter/IncrementalParser.cpp:143-156
+  // An initial PTU is needed as CUDA includes some headers automatically
+  auto PTU = ParseOrWrapTopLevelDecl();
+  if (auto E = PTU.takeError()) {
+consumeError(std::move(E)); // FIXME
+return; // PTU.takeError();
+  }
+

Should this be done as part of the "generic" `IncrementalParser` constructor, 
or only in the CUDA case by something else? Maybe `Interpreter::createWithCUDA`?



Comment at: clang/lib/Interpreter/Interpreter.cpp:270-274
+  if (DeviceParser) {
+auto DevicePTU = DeviceParser->Parse(Code);
+if (auto E = DevicePTU.takeError())
+  return E;
+  }

Just wondering about the order here: Do we have to parse the device side first? 
Does it make a difference for diagnostics? Maybe you can add a comment about 
the choice here...



Comment at: clang/lib/Interpreter/Offload.cpp:1
+//===-- Offload.cpp - CUDA Offloading ---*- C++ 
-*-===//
+//

v.g.vassilev wrote:
> How about `DeviceOffload.cpp`?
Or `IncrementalCUDADeviceParser.cpp` for the moment - not sure what other 
classes will be added in the future, and if they should be in the same TU.



Comment at: clang/lib/Interpreter/Offload.cpp:90-91
+  PTXCode += '\0';
+  while (PTXCode.size() % 8)
+PTXCode += '\0';
+  return PTXCode.str();

Is padding to 8 bytes a requirement for PTX? Maybe add a coment...



Comment at: clang/lib/Interpreter/Offload.h:20
+
+class DeviceCodeInlinerAction;
+

unused


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Simeon Ehrig via Phabricator via cfe-commits]

SimeonEhrig added inline comments.



Comment at: clang/tools/clang-repl/ClangRepl.cpp:135
+std::move(CI), std::move(DeviceCI), OffloadArch,
+"/tmp/clang-repl.fatbin"));
+

v.g.vassilev wrote:
> To cover the case where platforms have no `/tmp` we could use 
> `fs::createTemporaryFile`. However, some platforms have read-only file 
> systems. What do we do there?
Actual, we can avoid temporary files completely. The reason, why the fatbinary 
code is written to a file is the following code in the code generator of the 
CUDA runtime functions:

https://github.com/llvm/llvm-project/blob/d9d840cdaf51a9795930750d1b91d614a3849137/clang/lib/CodeGen/CGCUDANV.cpp#L722-L732

In the past, I avoided to change the code, because this was an extra Clang 
patch for Cling.

Maybe we can use the llvm virtualFileSystem: 
https://llvm.org/doxygen/classllvm_1_1vfs_1_1InMemoryFileSystem.html
But this is just an idea. I have no experience, if this is working for us.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: clang/tools/clang-repl/ClangRepl.cpp:137
+
+ExitOnErr(Interp->LoadDynamicLibrary("libcudart.so"));
+  } else

tra wrote:
> v.g.vassilev wrote:
> > tra wrote:
> > > Is there any doc describing the big picture approach to CUDA REPL 
> > > implementation and how all the pieces tie together?
> > > 
> > > From the patch I see that we will compile GPU side of the code to PTX, 
> > > pack it into fatbinary, but it's not clear now do we get from there to 
> > > actually launching the kernels. Loading libcudart.so here also does not 
> > > appear to be tied to anything else. I do not see any direct API calls, 
> > > and the host-side compilation appears to be done w.o passing the GPU 
> > > binary to it, which would normally trigger generation of the glue code to 
> > > register the kernels with CUDA runtime. I may be missing something, too.
> > > 
> > > I assume the gaps will be filled in in future patches, but I'm still 
> > > curious about the overall plan.
> > > 
> > > 
> > Hi @tra, thanks for asking. Our reference implementation was done in Cling 
> > a while ago by @SimeonEhrig. One of his talks which I think describes well 
> > the big picture could be found here: 
> > https://compiler-research.org/meetings/#caas_04Mar2021
> Cling does ring the bell. The slides from the link above do look OK.
> 
There is also a video.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

> Initial interactive CUDA support for clang-repl

What should a user expect to be supported, functionality wise? I assume it 
should cover parsing and compilation. I'm not so sure about the execution. 
Should it be expected to actually launch kernels, or will that come in a future 
patch?




Comment at: clang/tools/clang-repl/ClangRepl.cpp:137
+
+ExitOnErr(Interp->LoadDynamicLibrary("libcudart.so"));
+  } else

v.g.vassilev wrote:
> tra wrote:
> > Is there any doc describing the big picture approach to CUDA REPL 
> > implementation and how all the pieces tie together?
> > 
> > From the patch I see that we will compile GPU side of the code to PTX, pack 
> > it into fatbinary, but it's not clear now do we get from there to actually 
> > launching the kernels. Loading libcudart.so here also does not appear to be 
> > tied to anything else. I do not see any direct API calls, and the host-side 
> > compilation appears to be done w.o passing the GPU binary to it, which 
> > would normally trigger generation of the glue code to register the kernels 
> > with CUDA runtime. I may be missing something, too.
> > 
> > I assume the gaps will be filled in in future patches, but I'm still 
> > curious about the overall plan.
> > 
> > 
> Hi @tra, thanks for asking. Our reference implementation was done in Cling a 
> while ago by @SimeonEhrig. One of his talks which I think describes well the 
> big picture could be found here: 
> https://compiler-research.org/meetings/#caas_04Mar2021
Cling does ring the bell. The slides from the link above do look OK.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a subscriber: SimeonEhrig.
v.g.vassilev added inline comments.



Comment at: clang/tools/clang-repl/ClangRepl.cpp:137
+
+ExitOnErr(Interp->LoadDynamicLibrary("libcudart.so"));
+  } else

tra wrote:
> Is there any doc describing the big picture approach to CUDA REPL 
> implementation and how all the pieces tie together?
> 
> From the patch I see that we will compile GPU side of the code to PTX, pack 
> it into fatbinary, but it's not clear now do we get from there to actually 
> launching the kernels. Loading libcudart.so here also does not appear to be 
> tied to anything else. I do not see any direct API calls, and the host-side 
> compilation appears to be done w.o passing the GPU binary to it, which would 
> normally trigger generation of the glue code to register the kernels with 
> CUDA runtime. I may be missing something, too.
> 
> I assume the gaps will be filled in in future patches, but I'm still curious 
> about the overall plan.
> 
> 
Hi @tra, thanks for asking. Our reference implementation was done in Cling a 
while ago by @SimeonEhrig. One of his talks which I think describes well the 
big picture could be found here: 
https://compiler-research.org/meetings/#caas_04Mar2021


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/tools/clang-repl/ClangRepl.cpp:27
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", 
llvm::cl::Hidden);
+

Where will clang-repl find CUDA headers? Generally speaking `--cuda-path` is 
essential for CUDA compilation as it's fairly common for users to have more 
than one CUDA SDK versions installed, or to have them installed in a 
non-default location.



Comment at: clang/tools/clang-repl/ClangRepl.cpp:137
+
+ExitOnErr(Interp->LoadDynamicLibrary("libcudart.so"));
+  } else

Is there any doc describing the big picture approach to CUDA REPL 
implementation and how all the pieces tie together?

From the patch I see that we will compile GPU side of the code to PTX, pack it 
into fatbinary, but it's not clear now do we get from there to actually 
launching the kernels. Loading libcudart.so here also does not appear to be 
tied to anything else. I do not see any direct API calls, and the host-side 
compilation appears to be done w.o passing the GPU binary to it, which would 
normally trigger generation of the glue code to register the kernels with CUDA 
runtime. I may be missing something, too.

I assume the gaps will be filled in in future patches, but I'm still curious 
about the overall plan.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

Thanks for working on this!




Comment at: clang/lib/Interpreter/Offload.cpp:1
+//===-- Offload.cpp - CUDA Offloading ---*- C++ 
-*-===//
+//

How about `DeviceOffload.cpp`?



Comment at: clang/tools/clang-repl/ClangRepl.cpp:135
+std::move(CI), std::move(DeviceCI), OffloadArch,
+"/tmp/clang-repl.fatbin"));
+

To cover the case where platforms have no `/tmp` we could use 
`fs::createTemporaryFile`. However, some platforms have read-only file systems. 
What do we do there?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146389

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

[PATCH] D146389: [clang-repl][CUDA] Initial interactive CUDA support for clang-repl

[Anubhab Ghosh via Phabricator via cfe-commits]

argentite created this revision.
Herald added subscribers: mattd, carlosgalvezp, yaxunl.
Herald added a project: All.
argentite updated this revision to Diff 507049.
argentite added a comment.
argentite updated this revision to Diff 510808.
argentite edited the summary of this revision.
argentite added reviewers: v.g.vassilev, sgraenitz, lhames.
argentite published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Use full name of CUDA library


argentite added a comment.

Clear LinkModules on every interpreter iteration


CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146389

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/lib/Interpreter/Offload.cpp
  clang/lib/Interpreter/Offload.h
  clang/tools/clang-repl/ClangRepl.cpp

Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -23,6 +23,9 @@
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 #include 
 
+static llvm::cl::opt CudaEnabled("cuda", llvm::cl::Hidden);
+static llvm::cl::opt OffloadArch("offload-arch", llvm::cl::Hidden);
+
 static llvm::cl::list
 ClangArgs("Xcc",
   llvm::cl::desc("Argument to pass to the CompilerInvocation"),
@@ -90,9 +93,29 @@
 return 0;
   }
 
+  std::unique_ptr DeviceCI;
+  if (CudaEnabled) {
+// initialize NVPTX backend
+LLVMInitializeNVPTXTargetInfo();
+LLVMInitializeNVPTXTarget();
+LLVMInitializeNVPTXTargetMC();
+LLVMInitializeNVPTXAsmPrinter();
+
+auto DeviceArgv = ClangArgv;
+
+DeviceCI = ExitOnErr(
+clang::IncrementalCudaCompilerBuilder::createDevice(DeviceArgv));
+  }
+
   // FIXME: Investigate if we could use runToolOnCodeWithArgs from tooling. It
   // can replace the boilerplate code for creation of the compiler instance.
-  auto CI = ExitOnErr(clang::IncrementalCompilerBuilder::create(ClangArgv));
+  std::unique_ptr CI;
+  if (CudaEnabled) {
+CI = ExitOnErr(clang::IncrementalCudaCompilerBuilder::createHost(
+ClangArgv, "/tmp/clang-repl.fatbin"));
+  } else {
+CI = ExitOnErr(clang::IncrementalCompilerBuilder::createCpp(ClangArgv));
+  }
 
   // Set an error handler, so that any LLVM backend diagnostics go through our
   // error handler.
@@ -102,7 +125,19 @@
   // Load any requested plugins.
   CI->LoadRequestedPlugins();
 
-  auto Interp = ExitOnErr(clang::Interpreter::create(std::move(CI)));
+  std::unique_ptr Interp;
+  if (CudaEnabled) {
+if (OffloadArch.empty()) {
+  OffloadArch = "sm_35";
+}
+Interp = ExitOnErr(clang::Interpreter::createWithCUDA(
+std::move(CI), std::move(DeviceCI), OffloadArch,
+"/tmp/clang-repl.fatbin"));
+
+ExitOnErr(Interp->LoadDynamicLibrary("libcudart.so"));
+  } else
+Interp = ExitOnErr(clang::Interpreter::create(std::move(CI)));
+
   for (const std::string  : OptInputs) {
 if (auto Err = Interp->ParseAndExecute(input))
   llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "error: ");
Index: clang/lib/Interpreter/Offload.h
===
--- /dev/null
+++ clang/lib/Interpreter/Offload.h
@@ -0,0 +1,47 @@
+//===--- Offload.h - CUDA Offloading *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements classes required for offloading to CUDA devices.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_INTERPRETER_OFFLOAD_H
+#define LLVM_CLANG_LIB_INTERPRETER_OFFLOAD_H
+
+#include "IncrementalParser.h"
+
+namespace clang {
+
+class DeviceCodeInlinerAction;
+
+class IncrementalCUDADeviceParser : public IncrementalParser {
+public:
+  IncrementalCUDADeviceParser(std::unique_ptr Instance,
+  llvm::LLVMContext , llvm::StringRef Arch,
+  llvm::StringRef FatbinFile, llvm::Error );
+
+  llvm::Expected
+  Parse(llvm::StringRef Input) override;
+
+  // Generate PTX for the last PTU
+  llvm::Expected GeneratePTX();
+
+  // Write last PTX to the fatbinary file
+  llvm::Error WriteFatbinary() const;
+
+  ~IncrementalCUDADeviceParser();
+
+protected:
+  int SMVersion;
+  std::string