P4 to Git Change 1210699 by yaxunl@yaxunl_stg_win50 on 2015/11/12 15:57:00

SWDEV-81805 - Fix compiler lib bug: incorrect type name %opencl.pipe_t0 is generated when using clang.

	Clang does not return llvm::Module. It saves the bitcode to a memory buffer and passed back to compiler lib, then bitcode reader is used to get llvm::Module. Clang and bitcode reader uses the same LLVMContext which is created earlier in aclCompileInternal. Since named struct types are shared between modules in LLVMContext. When bitcode reader loads the module, name collision happens for named struct types, which causes them to be postfixed with a number, e.g. %opencl.pipe_t => %opencl.pipe_t0.

	This causes failure in SPIR-V drop-in conformance test.

	The fix is to let clang uses a separate LLVMContext.

Affected files ...

... //depot/stg/opencl/drivers/opencl/compiler/lib/backends/common/frontend_clang.cpp#26 edit

rocclr/compiler/lib/backends/common/frontend_clang.cpp

@@ -11,6 +11,7 @@
 #include "utils/options.hpp"
 #include "utils/target_mappings.h"
 
+#include "llvm/IR/LLVMContext.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -129,7 +130,11 @@ int amdcl::ClangOCLFrontend::compileCommand(const std::string& src) {
   }
 
   // Set the LLVMContext for the front-end compilation.
-  ClangOptions.CompilerContext = &Context();
+  // Clang needs to use a separate LLVMContext since the generated bitcode
+  // needs to be loaded again. Using the same LLVMContext causes name collision
+  // for named struct types in bitcode loader.
+  llvm::LLVMContext ClangCtx;
+  ClangOptions.CompilerContext = &ClangCtx;
 
   if (amdOpts && amdOpts->isDumpFlagSet(amd::option::DUMP_CL)) {
     dumpSource(src, amdOpts);