[SYCL][CUDA] Inline cl namespace to simplify SYCL API usage #1

fwyzard · 2020-02-03T23:38:11Z

Synchronise the CUDA backend with the general SYCL changes from #974.

fwyzard · 2020-02-03T23:39:51Z

Fixes the build error:

[  2%] Building CXX object tools/sycl/plugins/cuda/CMakeFiles/pi_cuda.dir/pi_cuda.cpp.o
In file included from /data/user/fwyzard/sycl/llvm/sycl/include/CL/sycl/detail/pi.hpp:13,
                 from /data/user/fwyzard/sycl/llvm/sycl/plugins/cuda/pi_cuda.cpp:10:
/data/user/fwyzard/sycl/llvm/sycl/include/CL/sycl/detail/common.hpp:25:25: error: inline namespace must be specified at initial definition
 __SYCL_INLINE namespace cl {
                         ^~
In file included from /data/user/fwyzard/sycl/llvm/sycl/plugins/cuda/pi_cuda.cpp:9:
/data/user/fwyzard/sycl/llvm/sycl/include/CL/sycl/backend/cuda.hpp:9:11: note: 'cl' defined here
 namespace cl {
           ^~

Alexander-Johnston · 2020-02-05T11:04:03Z

Thanks for this, looks good.

Can you add the Signed-off-by: name <email> section to the end of the commit message required by Intel's CI please, then we can merge this.

Synchronise the CUDA backend with the general SYCL changes from intel#974. Signed-off-by: Andrea Bocci <andrea.bocci@cern.ch>

fwyzard · 2020-02-05T17:25:00Z

Sure, done.

CONFLICT (content): Merge conflict in clang/lib/Sema/SemaChecking.cpp

The code changes here are hopefully straightforward: 1. Use MachineInstruction flags to decide if FP ops can be reassociated (use both "reassoc" and "nsz" to be consistent with IR transforms; we probably don't need "nsz", but that's a safer interpretation of the FMF). 2. Check that both nodes allow reassociation to change instructions. This is a stronger requirement than we've usually implemented in IR/DAG, but this is needed to solve the motivating bug (see below), and it seems unlikely to impede optimization at this late stage. 3. Intersect/propagate MachineIR flags to enable further reassociation in MachineCombiner. We managed to make MachineCombiner flexible enough that no changes are needed to that pass itself. So this patch should only affect x86 (assuming no other targets have implemented the hooks using MachineIR flags yet). The motivating example in PR43609 is another case of fast-math transforms interacting badly with special FP ops created during lowering: https://bugs.llvm.org/show_bug.cgi?id=43609 The special fadd ops used for converting int to FP assume that they will not be altered, so those are created without FMF. However, the MachineCombiner pass was being enabled for FP ops using the global/function-level TargetOption for "UnsafeFPMath". We managed to run instruction/node-level FMF all the way down to MachineIR sometime in the last 1-2 years though, so we can do better now. The test diffs require some explanation: 1. llvm/test/CodeGen/X86/fmf-flags.ll - no target option for unsafe math was specified here, so MachineCombiner kicks in where it did not previously; to make it behave consistently, we need to specify a CPU schedule model, so use the default model, and there are no code diffs. 2. llvm/test/CodeGen/X86/machine-combiner.ll - replace the target option for unsafe math with the equivalent IR-level flags, and there are no code diffs; we can't remove the NaN/nsz options because those are still used to drive x86 fmin/fmax codegen (special SDAG opcodes). 3. llvm/test/CodeGen/X86/pow.ll - similar to #1 4. llvm/test/CodeGen/X86/sqrt-fastmath.ll - similar to #1, but MachineCombiner does some reassociation of the estimate sequence ops; presumably these are perf wins based on latency/throughput (and we get some reduction of move instructions too); I'm not sure how it affects numerical accuracy, but the test reflects reality better now because we would expect MachineCombiner to be enabled if the IR was generated via something like "-ffast-math" with clang. 5. llvm/test/CodeGen/X86/vec_int_to_fp.ll - this is the test added to model PR43609; the fadds are not reassociated now, so we should get the expected results. 6. llvm/test/CodeGen/X86/vector-reduce-fadd-fast.ll - similar to #1 7. llvm/test/CodeGen/X86/vector-reduce-fmul-fast.ll - similar to #1 Differential Revision: https://reviews.llvm.org/D74851

CONFLICT (content): Merge conflict in clang/include/clang/Sema/ParsedAttr.h

This reverts commit dfecec6. Merging the change revealed that there is a failure on the memory sanitizer bots. Command Output (stderr): -- ==3569==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x1d71bff in llvm::AVRSubtarget::ParseSubtargetFeatures(llvm::StringRef, llvm::StringRef) /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/Target/AVR/AVRGenSubtargetInfo.inc:471:7 #1 0x1d721f8 in initializeSubtargetDependencies /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRSubtarget.cpp:50:3 #2 0x1d721f8 in llvm::AVRSubtarget::AVRSubtarget(llvm::Triple const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, llvm::AVRTargetMachine const&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRSubtarget.cpp:33:18 #3 0x1d3077f in llvm::AVRTargetMachine::AVRTargetMachine(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>, llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRTargetMachine.cpp:52:7 #4 0x1d3169d in llvm::RegisterTargetMachine<llvm::AVRTargetMachine>::Allocator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>, llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/TargetRegistry.h:1121:16 #5 0x86662f in createTargetMachine /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/TargetRegistry.h:402:12 #6 0x86662f in compileModule(char**, llvm::LLVMContext&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:473:52 #7 0x861f42 in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:356:22 #8 0x7f76f7b072e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #9 0x7ebbc9 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/llc+0x7ebbc9) SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/Target/AVR/AVRGenSubtargetInfo.inc:471:7 in llvm::AVRSubtarget::ParseSubtargetFeatures(llvm::StringRef, llvm::StringRef) Exiting FileCheck error: '<stdin>' is empty. -- The patch wiill be re-committed once fixed.

CONFLICT (content): Merge conflict in clang/include/clang/Basic/Attr.td

CONFLICT (content): Merge conflict in clang/test/Driver/sycl.c

Summary: This patch adds IR intrinsics for vector-predicated integer arithmetic. It is subpatch #1 of the [integer slice](https://reviews.llvm.org/D57504#1732277) of [LLVM-VP](https://reviews.llvm.org/D57504). LLVM-VP is a larger effort to bring native vector predication to LLVM. Reviewed By: andrew.w.kaylor Differential Revision: https://reviews.llvm.org/D69891

CONFLICT (content): Merge conflict in README.md

ADDI often has a frameindex in operand 1, but consumers of this interface, such as MachineSink, tend to call getReg() on the Destination and Source operands, leading to the following crash when building FreeBSD after this implementation was added in 8cf6778: ``` clang: llvm/include/llvm/CodeGen/MachineOperand.h:359: llvm::Register llvm::MachineOperand::getReg() const: Assertion `isReg() && "This is not a register operand!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: #0 0x00007f4286f9b4d0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) llvm/lib/Support/Unix/Signals.inc:563:0 #1 0x00007f4286f9b587 PrintStackTraceSignalHandler(void*) llvm/lib/Support/Unix/Signals.inc:630:0 #2 0x00007f4286f9926b llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:71:0 #3 0x00007f4286f9ae52 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:405:0 #4 0x00007f428646ffd0 (/lib/x86_64-linux-gnu/libc.so.6+0x3efd0) #5 0x00007f428646ff47 raise /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #6 0x00007f42864718b1 abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:81:0 #7 0x00007f428646142a __assert_fail_base /build/glibc-2ORdQG/glibc-2.27/assert/assert.c:89:0 #8 0x00007f42864614a2 (/lib/x86_64-linux-gnu/libc.so.6+0x304a2) #9 0x00007f428d4078e2 llvm::MachineOperand::getReg() const llvm/include/llvm/CodeGen/MachineOperand.h:359:0 #10 0x00007f428d8260e7 attemptDebugCopyProp(llvm::MachineInstr&, llvm::MachineInstr&) llvm/lib/CodeGen/MachineSink.cpp:862:0 #11 0x00007f428d826442 performSink(llvm::MachineInstr&, llvm::MachineBasicBlock&, llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>, llvm::SmallVectorImpl<llvm::MachineInstr*>&) llvm/lib/CodeGen/MachineSink.cpp:918:0 #12 0x00007f428d826e27 (anonymous namespace)::MachineSinking::SinkInstruction(llvm::MachineInstr&, bool&, std::map<llvm::MachineBasicBlock*, llvm::SmallVector<llvm::MachineBasicBlock*, 4u>, std::less<llvm::MachineBasicBlock*>, std::allocator<std::pair<llvm::MachineBasicBlock* const, llvm::SmallVector<llvm::MachineBasicBlock*, 4u> > > >&) llvm/lib/CodeGen/MachineSink.cpp:1073:0 #13 0x00007f428d824a2c (anonymous namespace)::MachineSinking::ProcessBlock(llvm::MachineBasicBlock&) llvm/lib/CodeGen/MachineSink.cpp:410:0 #14 0x00007f428d824513 (anonymous namespace)::MachineSinking::runOnMachineFunction(llvm::MachineFunction&) llvm/lib/CodeGen/MachineSink.cpp:340:0 ``` Thus, check that operand 1 is also a register in the condition. Reviewed By: arichardson, luismarques Differential Revision: https://reviews.llvm.org/D89090

Depends on D89408. This diff finally implements trace decoding! The current interface is $ trace load /path/to/trace/session/file.json $ thread trace dump instructions thread #1: tid = 3842849, total instructions = 22 [ 0] 0x40052d [ 1] 0x40052d ... [19] 0x400521 $ # simply enter, which is a repeat command [20] 0x40052d [21] 0x400529 ... This doesn't do any disassembly, which will be done in the next diff. Changes: - Added an IntelPTDecoder class, that is a wrapper for libipt, which is the actual library that performs the decoding. - Added TraceThreadDecoder class that decodes traces and memoizes the result to avoid repeating the decoding step. - Added a DecodedThread class, which represents the output from decoding and that for the time being only stores the list of reconstructed instructions. Later it'll contain the function call hierarchy, which will enable reconstructing backtraces. - Added basic APIs for accessing the trace in Trace.h: - GetInstructionCount, which counts the number of instructions traced for a given thread - IsTraceFailed, which returns an Error if decoding a thread failed - ForEachInstruction, which iterates on the instructions traced for a given thread, concealing the internal storage of threads, as plug-ins can decide to generate the instructions on the fly or to store them all in a vector, like I do. - DumpTraceInstructions was updated to print the instructions or show an error message if decoding was impossible. - Tests included Differential Revision: https://reviews.llvm.org/D89283

Tracking local variables across suspend points is still somewhat incomplete. Consider this coroutine snippet: ``` resumable foo() { int x[10] = {}; int a = 3; co_await std::experimental::suspend_always(); a++; x[0] = 1; a += 2; x[1] = 2; a += 3; x[2] = 3; } ``` Can't manage to print `a` or `x` if they turn out to be allocas during CoroSplit (which happens if you build this code with `-O0` prior to this commit): ``` * thread #1, queue = 'com.apple.main-thread', stop reason = step over frame #0: 0x0000000100003729 main-noprint`foo() at main-noprint.cpp:43:5 40 co_await std::experimental::suspend_always(); 41 a++; 42 x[0] = 1; -> 43 a += 2; 44 x[1] = 2; 45 a += 3; 46 x[2] = 3; (lldb) p x error: <user expression 21>:1:1: use of undeclared identifier 'x' x ^ ``` The generated IR contains a `llvm.dbg.declare` for `x` in it's initialization basic block. After CoroSplit, the `llvm.dbg.declare` might not dominate all of `x` uses and we lose debugging quality. Add `llvm.dbg.value`s to all relevant basic blocks such that if later transformations break the dominance the reliable debug info is already in place. For instance, this BB: ``` await.ready: ... %arrayidx = getelementptr inbounds [10 x i32], [10 x i32]* %x.reload.addr, i64 0, i64 0, !dbg !760 ... %arrayidx19 = getelementptr inbounds [10 x i32], [10 x i32]* %x.reload.addr, i64 0, i64 1, !dbg !763 ... %arrayidx21 = getelementptr inbounds [10 x i32], [10 x i32]* %x.reload.addr, i64 0, i64 2, !dbg !766 ``` becomes: ``` await.ready: ... call void @llvm.dbg.value(metadata [10 x i32]* %x.reload.addr, metadata !751, metadata !DIExpression()), !dbg !753 ... %arrayidx = getelementptr inbounds [10 x i32], [10 x i32]* %x.reload.addr, i64 0, i64 0, !dbg !760 ... %arrayidx19 = getelementptr inbounds [10 x i32], [10 x i32]* %x.reload.addr, i64 0, i64 1, !dbg !763 ... %arrayidx21 = getelementptr inbounds [10 x i32], [10 x i32]* %x.reload.addr, i64 0, i64 2, !dbg !766 ``` Differential Revision: https://reviews.llvm.org/D90772

CONFLICT (content): Merge conflict in clang/lib/CodeGen/CGLoopInfo.cpp

CONFLICT (content): Merge conflict in clang/utils/TableGen/TableGen.cpp

CONFLICT (content): Merge conflict in llvm/lib/Transforms/IPO/PassManagerBuilder.cpp

CONFLICT (content): Merge conflict in clang/include/clang/AST/PrettyPrinter.h

CONFLICT (content): Merge conflict in clang/lib/CodeGen/CodeGenTypes.cpp CONFLICT (content): Merge conflict in clang/lib/AST/Decl.cpp CONFLICT (content): Merge conflict in clang/include/clang/AST/PrettyPrinter.h

CONFLICT (content): Merge conflict in clang/test/SemaOpenCLCXX/address-space-lambda.cl

This reverts commit bfd2c21. This appears to be causing stage2 msan failures on buildbots: FAIL: LLVM :: Transforms/SimplifyCFG/X86/bug-25299.ll (65872 of 71835) ******************** TEST 'LLVM :: Transforms/SimplifyCFG/X86/bug-25299.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/opt < /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/test/Transforms/SimplifyCFG/X86/bug-25299.ll -simplifycfg -S | /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/FileCheck /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/test/Transforms/SimplifyCFG/X86/bug-25299.ll -- Exit Code: 2 Command Output (stderr): -- ==87374==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x9de47b6 in getBasicBlockIndex /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/IR/Instructions.h:2749:5 #1 0x9de47b6 in simplifyCommonResume /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:4112:23 #2 0x9de47b6 in simplifyResume /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:4039:12 #3 0x9de47b6 in (anonymous namespace)::SimplifyCFGOpt::simplifyOnce(llvm::BasicBlock*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:6330:16 #4 0x9dcca13 in run /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:6358:16 #5 0x9dcca13 in llvm::simplifyCFG(llvm::BasicBlock*, llvm::TargetTransformInfo const&, llvm::SimplifyCFGOptions const&, llvm::SmallPtrSetImpl<llvm::BasicBlock*>*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:6369:8 #6 0x974643d in iterativelySimplifyCFG(

…e tools This is the #1 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow the threshold to sync with hotness threshold from profile summary with special value 'auto'. This change modifies the interface of lto::setupLLVMOptimizationRemarks() to accept remarks hotness threshold. Update all the tools that use it with remarks hotness threshold options: * lld: '--opt-remarks-hotness-threshold=' * llvm-lto2: '--pass-remarks-hotness-threshold=' * llvm-lto: '--lto-pass-remarks-hotness-threshold=' * gold plugin: '-plugin-opt=opt-remarks-hotness-threshold=' Differential Revision: https://reviews.llvm.org/D85809

CONFLICT (content): Merge conflict in llvm/lib/Transforms/IPO/PassManagerBuilder.cpp

CXXDeductionGuideDecl with a local typedef has its own copy of the TypedefDecl with the CXXDeductionGuideDecl as the DeclContext of that TypedefDecl. ``` template <typename T> struct A { typedef T U; A(U, T); }; A a{(int)0, (int)0}; ``` Related discussion on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2020-November/067252.html Without this fix, when we import the CXXDeductionGuideDecl (via VisitFunctionDecl) then before creating the Decl we must import the FunctionType. However, the first parameter's type is the afore mentioned local typedef. So, we then start importing the TypedefDecl whose DeclContext is the CXXDeductionGuideDecl itself. The infinite loop is formed. ``` #0 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0 #1 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:405:0 #2 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0 #3 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0 #4 clang::ASTImporter::ImportContext(clang::DeclContext*) clang/lib/AST/ASTImporter.cpp:8297:0 #5 clang::ASTNodeImporter::ImportDeclContext(clang::Decl*, clang::DeclContext*&, clang::DeclContext*&) clang/lib/AST/ASTImporter.cpp:1852:0 #6 clang::ASTNodeImporter::ImportDeclParts(clang::NamedDecl*, clang::DeclContext*&, clang::DeclContext*&, clang::DeclarationName&, clang::NamedDecl*&, clang::SourceLocation&) clang/lib/AST/ASTImporter.cpp:1628:0 #7 clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool) clang/lib/AST/ASTImporter.cpp:2419:0 #8 clang::ASTNodeImporter::VisitTypedefDecl(clang::TypedefDecl*) clang/lib/AST/ASTImporter.cpp:2500:0 #9 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:315:0 #10 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0 #11 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0 #12 llvm::Expected<clang::TypedefNameDecl*> clang::ASTNodeImporter::import<clang::TypedefNameDecl>(clang::TypedefNameDecl*) clang/lib/AST/ASTImporter.cpp:165:0 #13 clang::ASTNodeImporter::VisitTypedefType(clang::TypedefType const*) clang/lib/AST/ASTImporter.cpp:1304:0 #14 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:74:0 #15 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0 #16 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0 #17 clang::ASTNodeImporter::VisitFunctionProtoType(clang::FunctionProtoType const*) clang/lib/AST/ASTImporter.cpp:1244:0 #18 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:47:0 #19 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0 #20 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0 #21 clang::QualType clang::ASTNodeImporter::importChecked<clang::QualType>(llvm::Error&, clang::QualType const&) clang/lib/AST/ASTImporter.cpp:198:0 #22 clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) clang/lib/AST/ASTImporter.cpp:3313:0 #23 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0 ``` The fix is to first create the TypedefDecl and only then start to import the DeclContext. Basically, we could do this during the import of all other Decls (not just for typedefs). But it seems, there is only one another AST construct that has a similar cycle: a struct defined as a function parameter: ``` int struct_in_proto(struct data_t{int a;int b;} *d); ``` In that case, however, we had decided to return simply with an error back then because that seemed to be a very rare construct. Differential Revision: https://reviews.llvm.org/D92209

CONFLICT (content): Merge conflict in clang/lib/Sema/SemaTemplateInstantiateDecl.cpp

CONFLICT (content): Merge conflict in clang/test/Misc/nvptx.languageOptsOpenCL.cl CONFLICT (content): Merge conflict in clang/lib/Sema/SemaType.cpp

… disabled for a PCH vs a module file This addresses an issue with how the PCH preable works, specifically: 1. When using a PCH/preamble the module hash changes and a different cache directory is used 2. When the preamble is used, PCH & PCM validation is disabled. Due to combination of #1 and #2, reparsing with preamble enabled can end up loading a stale module file before a header change and using it without updating it because validation is disabled and it doesn’t check that the header has changed and the module file is out-of-date. rdar://72611253 Differential Revision: https://reviews.llvm.org/D95159

CONFLICT (content): Merge conflict in clang/include/clang/Driver/Options.td

Ruyk requested a review from Alexander-Johnston February 4, 2020 09:46

Alexander-Johnston force-pushed the cuda branch from 3519fcd to cbf3431 Compare February 4, 2020 11:35

fwyzard force-pushed the cuda_inline_cl_namespace branch from 897a43a to 0dfd7d0 Compare February 4, 2020 23:56

Alexander-Johnston approved these changes Feb 5, 2020

View reviewed changes

[SYCL][CUDA] Inline cl namespace to simplify SYCL API usage

21c3b3d

Synchronise the CUDA backend with the general SYCL changes from intel#974. Signed-off-by: Andrea Bocci <andrea.bocci@cern.ch>

fwyzard force-pushed the cuda_inline_cl_namespace branch from 0dfd7d0 to 21c3b3d Compare February 5, 2020 17:24

Alexander-Johnston merged this pull request into codeplaysoftware:cuda Feb 6, 2020

fwyzard deleted the cuda_inline_cl_namespace branch February 6, 2020 18:07

codeplay-sycl pushed a commit that referenced this pull request Feb 11, 2020

Merge from 'sycl' to 'sycl-web' (#1)

ef666b1

fwyzard mentioned this pull request Feb 13, 2020

[SYCL][CUDA] Refactor __SYCL_INLINE macro #4

Merged

codeplay-sycl pushed a commit that referenced this pull request Feb 18, 2020

Merge from 'sycl' to 'sycl-web' (#1)

0c785d3

codeplay-sycl pushed a commit that referenced this pull request Feb 18, 2020

Merge from 'sycl' to 'sycl-web' (#1)

fd438ca

codeplay-sycl pushed a commit that referenced this pull request Feb 26, 2020

Merge from 'master' to 'sycl-web' (#1)

ff5b5cf

CONFLICT (content): Merge conflict in clang/lib/Sema/SemaChecking.cpp

codeplay-sycl pushed a commit that referenced this pull request Mar 10, 2020

Merge from 'master' to 'sycl-web' (#1)

36b0516

codeplay-sycl pushed a commit that referenced this pull request Mar 10, 2020

Merge from 'sycl' to 'sycl-web' (#1)

237e8be

codeplay-sycl pushed a commit that referenced this pull request Mar 10, 2020

Merge from 'sycl' to 'sycl-web' (#1)

08318b7

codeplay-sycl pushed a commit that referenced this pull request Mar 10, 2020

Merge from 'master' to 'sycl-web' (#1)

a395423

codeplay-sycl pushed a commit that referenced this pull request Mar 10, 2020

Merge from 'master' to 'sycl-web' (#1)

0df8a77

CONFLICT (content): Merge conflict in clang/include/clang/Sema/ParsedAttr.h

codeplay-sycl pushed a commit that referenced this pull request Mar 10, 2020

Merge from 'master' to 'sycl-web' (#1)

b1082b7

codeplay-sycl pushed a commit that referenced this pull request Mar 17, 2020

Merge from 'master' to 'sycl-web' (#1)

b93fda8

codeplay-sycl pushed a commit that referenced this pull request Mar 17, 2020

Merge from 'master' to 'sycl-web' (#1)

0473a18

codeplay-sycl pushed a commit that referenced this pull request Mar 17, 2020

Merge from 'master' to 'sycl-web' (#1)

f077a2d

codeplay-sycl pushed a commit that referenced this pull request Mar 17, 2020

Merge from 'master' to 'sycl-web' (#1)

1fd087d

CONFLICT (content): Merge conflict in clang/include/clang/Basic/Attr.td

codeplay-sycl pushed a commit that referenced this pull request Mar 17, 2020

Merge from 'sycl' to 'sycl-web' (#1)

a9bcb4f

CONFLICT (content): Merge conflict in clang/test/Driver/sycl.c

codeplay-sycl pushed a commit that referenced this pull request Oct 28, 2020

Merge from 'master' to 'sycl-web' (#1)

cbe0886

CONFLICT (content): Merge conflict in README.md

codeplay-sycl pushed a commit that referenced this pull request Nov 12, 2020

Merge from 'master' to 'sycl-web' (#1)

1d0d565

codeplay-sycl pushed a commit that referenced this pull request Nov 12, 2020

Merge from 'master' to 'sycl-web' (#1)

194afac

CONFLICT (content): Merge conflict in clang/lib/CodeGen/CGLoopInfo.cpp

codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020

Merge from 'master' to 'sycl-web' (#1)

da93b6e

CONFLICT (content): Merge conflict in clang/utils/TableGen/TableGen.cpp

codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020

Merge from 'master' to 'sycl-web' (#1)

524dad4

CONFLICT (content): Merge conflict in llvm/lib/Transforms/IPO/PassManagerBuilder.cpp

codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020

Merge from 'master' to 'sycl-web' (#1)

0f3c3af

codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020

Merge from 'sycl' to 'sycl-web' (#1)

341d71d

codeplay-sycl pushed a commit that referenced this pull request Nov 20, 2020

Merge from 'master' to 'sycl-web' (#1)

83a1d2a

CONFLICT (content): Merge conflict in clang/include/clang/AST/PrettyPrinter.h

codeplay-sycl pushed a commit that referenced this pull request Nov 24, 2020

Merge from 'master' to 'sycl-web' (#1)

6434b9c

CONFLICT (content): Merge conflict in clang/test/SemaOpenCLCXX/address-space-lambda.cl

codeplay-sycl pushed a commit that referenced this pull request Dec 1, 2020

Merge from 'master' to 'sycl-web' (#1)

bed8916

CONFLICT (content): Merge conflict in llvm/lib/Transforms/IPO/PassManagerBuilder.cpp

codeplay-sycl pushed a commit that referenced this pull request Dec 9, 2020

Merge from 'master' to 'sycl-web' (#1)

69224a7

codeplay-sycl pushed a commit that referenced this pull request Dec 22, 2020

Merge from 'master' to 'sycl-web' (#1)

de88506

CONFLICT (content): Merge conflict in clang/lib/Sema/SemaTemplateInstantiateDecl.cpp

codeplay-sycl pushed a commit that referenced this pull request Dec 22, 2020

Merge from 'master' to 'sycl-web' (#1)

a7c0c81

codeplay-sycl pushed a commit that referenced this pull request Dec 25, 2020

Merge from 'sycl' to 'sycl-web' (#1)

9c6c41b

codeplay-sycl pushed a commit that referenced this pull request Jan 21, 2021

Merge from 'main' to 'sycl-web' (#1)

e2bf40f

CONFLICT (content): Merge conflict in clang/test/Misc/nvptx.languageOptsOpenCL.cl CONFLICT (content): Merge conflict in clang/lib/Sema/SemaType.cpp

codeplay-sycl pushed a commit that referenced this pull request Jan 21, 2021

Merge from 'sycl' to 'sycl-web' (#1)

8d13123

codeplay-sycl pushed a commit that referenced this pull request Jan 21, 2021

Merge from 'sycl' to 'sycl-web' (#1)

cd7f8da

codeplay-sycl pushed a commit that referenced this pull request Jan 28, 2021

Merge from 'main' to 'sycl-web' (#1)

7a7401f

CONFLICT (content): Merge conflict in clang/include/clang/Driver/Options.td

codeplay-sycl pushed a commit that referenced this pull request Jan 28, 2021

Merge from 'sycl' to 'sycl-web' (#1)

251377e

codeplay-sycl pushed a commit that referenced this pull request Feb 5, 2021

Merge from 'sycl' to 'sycl-web' (#1)

2c106cc

codeplay-sycl pushed a commit that referenced this pull request Feb 5, 2021

Merge from 'sycl' to 'sycl-web' (#1)

7989e30

codeplay-sycl pushed a commit that referenced this pull request Feb 5, 2021

Merge from 'main' to 'sycl-web' (#1)

6b85739

CONFLICT (content): Merge conflict in clang/include/clang/Driver/Options.td

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SYCL][CUDA] Inline cl namespace to simplify SYCL API usage #1

[SYCL][CUDA] Inline cl namespace to simplify SYCL API usage #1

fwyzard commented Feb 3, 2020

fwyzard commented Feb 3, 2020

Alexander-Johnston commented Feb 5, 2020

fwyzard commented Feb 5, 2020

[SYCL][CUDA] Inline cl namespace to simplify SYCL API usage #1

[SYCL][CUDA] Inline cl namespace to simplify SYCL API usage #1

Conversation

fwyzard commented Feb 3, 2020

fwyzard commented Feb 3, 2020

Alexander-Johnston commented Feb 5, 2020

fwyzard commented Feb 5, 2020