Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SYCL] Support Split Device Compilation #9

Open
agozillon opened this issue Apr 15, 2019 · 0 comments
Open

[SYCL] Support Split Device Compilation #9

agozillon opened this issue Apr 15, 2019 · 0 comments
Labels
enhancement New feature or request

Comments

@agozillon
Copy link
Contributor

Currently we only really support single step compilation of SYCL source code to end binary output. However, it's entirely possible to support two step compilation if we wish, this could allow generation of a SPIR binary or XCL binary (xocc output binary after compilation and linking).

I'm not sure how important the XCL binary use-case is, but the SPIR binary output is pretty useful e.g. SYCL offloading to POCL. It also lets you debug the SPIR output a little easier and run additional passes without needing to alter the compiler too much.

There was functionality in place for two step compilation originally in the SYCL up-streaming implementation e.g. in the Build and Test a simple SYCL program section: https://github.com/intel/llvm/blob/e7219557e61e03d59db89346cf43a53e103973ed/sycl/doc/GetStartedWithSYCLCompiler.md

It seems to still exist but it's no longer documented for the time being, so it may require some maintenance. The above device side step can be hooked into with an optional -fsycl-use-bitcode flag to generate LLVM-IR. Although, without the InSPIRation pass being ran on the output the LLVM-IR still contains SPIRV builtins.

To truly get some form of SPIR-df you would need to run the LLVM-IR through our InSPIRation pass at the moment. Having this done cleanly through a compiler invocation is the tricky part. With this final output it should be possible to use the SPIR-df output with a POCL runtime using the second command (I had some success with this in the past, although there are some issues with certain builtins at the moment: pocl/pocl#698 this should be tackled in a separate issue however)

XCL binary support is probably a different beast, as it requires you to invoke just the xocc component of the SYCL ToolChain without any additional offloading and wrapping steps into a final binary.
@agozillon agozillon added the enhancement New feature or request label Apr 15, 2019
@agozillon agozillon mentioned this issue Apr 15, 2019
Open
Ralender pushed a commit to Ralender/sycl that referenced this issue Jul 1, 2020
Merge from 'sycl' to 'sycl-web' (triSYCL#9)
30d3a8b
Ralender pushed a commit to Ralender/sycl that referenced this issue Jul 1, 2020
@bader
Merge from 'master' to 'sycl-web' (triSYCL#9)
407bb95 
  CONFLICT (content): Merge conflict in clang/lib/CodeGen/CGExpr.cpp
Ralender pushed a commit to Ralender/sycl that referenced this issue Jul 1, 2020
Merge from 'sycl' to 'sycl-web' (triSYCL#9)
6f48d6f
Ralender pushed a commit to Ralender/sycl that referenced this issue Oct 27, 2020
@aelovikov-intel
Merge from 'master' to 'sycl-web' (triSYCL#9)
e79b586 
  CONFLICT (content): Merge conflict in clang/include/clang/Basic/DiagnosticDriverKinds.td
keryell pushed a commit that referenced this issue Apr 28, 2021
@dm-vodopyanov
Merge from 'main' to 'sycl-web' (#9)
e8cdd2a 
  CONFLICT (content): Merge conflict in clang/lib/Frontend/CompilerInvocation.cpp
keryell pushed a commit that referenced this issue Feb 21, 2022
@joker-eph
Revert "[MLIR] rewrite AffineStructures and Presburger tests to use t…
6963be1 
…he parser"

This reverts commit b0e8667.

ASAN/UBSAN bot is broken with this trace:

[ RUN      ] FlatAffineConstraintsTest.FindSampleTest
llvm-project/mlir/include/mlir/Support/MathExtras.h:27:15: runtime error: signed integer overflow: 1229996100002 * 809999700000 cannot be represented in type 'long'
    #0 0x7f63ace960e4 in mlir::ceilDiv(long, long) llvm-project/mlir/include/mlir/Support/MathExtras.h:27:15
    #1 0x7f63ace8587e in ceil llvm-project/mlir/include/mlir/Analysis/Presburger/Fraction.h:57:42
    #2 0x7f63ace8587e in operator* llvm-project/llvm/include/llvm/ADT/STLExtras.h:347:42
    #3 0x7f63ace8587e in uninitialized_copy<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, long *> include/c++/v1/__memory/uninitialized_algorithms.h:36:62
    #4 0x7f63ace8587e in uninitialized_copy<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, long *> llvm-project/llvm/include/llvm/ADT/SmallVector.h:490:5
    #5 0x7f63ace8587e in append<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, void> llvm-project/llvm/include/llvm/ADT/SmallVector.h:662:5
    #6 0x7f63ace8587e in SmallVector<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long> > llvm-project/llvm/include/llvm/ADT/SmallVector.h:1204:11
    #7 0x7f63ace8587e in mlir::FlatAffineConstraints::findIntegerSample() const llvm-project/mlir/lib/Analysis/AffineStructures.cpp:1171:27
    #8 0x7f63ae95a84d in mlir::checkSample(bool, mlir::FlatAffineConstraints const&, mlir::TestFunction) llvm-project/mlir/unittests/Analysis/AffineStructuresTest.cpp:37:23
    #9 0x7f63ae957545 in mlir::FlatAffineConstraintsTest_FindSampleTest_Test::TestBody() llvm-project/mlir/unittests/Analysis/AffineStructuresTest.cpp:222:3
keryell pushed a commit that referenced this issue Oct 6, 2022
@palves @dwblaikie
llvm-dwarfdump: Don't crash if DW_AT_{decl,call}_{file,line} uses sig…
ac6df7f 
…ned form

The DWARF spec says:

 Any debugging information entry representing the declaration of an object,
 module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
 DW_AT_decl_column attributes, each of whose value is an unsigned integer
							 ^^^^^^^^
 constant.

If however, a producer happens to emit DW_AT_decl_file /
DW_AT_decl_line using a signed integer form, llvm-dwarfdump crashes,
like so:

     (... snip ...)
     0x000000b4:   DW_TAG_structure_type
                     DW_AT_name      ("test_struct")
                     DW_AT_byte_size (136)
                     DW_AT_decl_file (llvm-dwarfdump: (... snip ...)/llvm/include/llvm/ADT/Optional.h:197: T& llvm::optional_detail::OptionalStorage<T, true>::getValue() &
 [with T = long unsigned int]: Assertion `hasVal' failed.
     PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
     Stack dump:
     0.      Program arguments: /opt/rocm/llvm/bin/llvm-dwarfdump ./testsuite/outputs/gdb.rocm/lane-pc-vega20/lane-pc-vega20-kernel.so
      #0 0x000055cc8e78315f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
      #1 0x000055cc8e780d3d SignalHandler(int) Signals.cpp:0:0
      #2 0x00007f8f2cae8420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
      #3 0x00007f8f2c58d00b raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
      #4 0x00007f8f2c56c859 abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:81:7
      #5 0x00007f8f2c56c729 get_sysdep_segment_value /build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c:509:8
      #6 0x00007f8f2c56c729 _nl_load_domain /build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c:970:34
      #7 0x00007f8f2c57dfd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
      #8 0x000055cc8e58ceb9 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const (/opt/rocm/llvm/bin/llvm-dwarfdump+0x2e0eb9)
      #9 0x000055cc8e58bec3 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const (/opt/rocm/llvm/bin/llvm-dwarfdump+0x2dfec3)
     #10 0x000055cc8e5b28a3 llvm::DWARFCompileUnit::dump(llvm::raw_ostream&, llvm::DIDumpOptions) (.part.21) DWARFCompileUnit.cpp:0:0

Likewise with DW_AT_call_file / DW_AT_call_line.

The problem is that the code in llvm/lib/DebugInfo/DWARF/DWARFDie.cpp
dumping these attributes assumes that
FormValue.getAsUnsignedConstant() returns an armed optional.  If in
debug mode, we get an assertion line the above.  If in release mode,
and asserts are compiled out, then we proceed as if the optional had a
value, running into undefined behavior, printing whatever random
value.

Fix this by checking whether the optional returned by
FormValue.getAsUnsignedConstant() has a value, like done in other
places.

In addition, DWARFVerifier.cpp is validating DW_AT_call_file /
DW_AT_decl_file, but not AT_call_line / DW_AT_decl_line.  This commit
fixes that too.

The llvm-dwarfdump/X86/verify_file_encoding.yaml testcase is extended
to cover these cases.  Current llvm-dwarfdump crashes running the
newly-extended test.

"make check-llvm-tools-llvm-dwarfdump" shows no regressions, on x86-64
GNU/Linux.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D129392
keryell pushed a commit that referenced this issue Jan 4, 2023
@d0k
[clang][Interp] Reorder field destruction to avoid use after dtor
da4b929 
Found by msan -fsanitize-memory-use-after-dtor.

==8259==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x55dbec54d2b8 in dtorRecord(clang::interp::Block*, char*, clang::interp::Descriptor*) clang/lib/AST/Interp/Descriptor.cpp:150:22
    #1 0x55dbec54bfcf in dtorArrayDesc(clang::interp::Block*, char*, clang::interp::Descriptor*) clang/lib/AST/Interp/Descriptor.cpp:97:7
    #2 0x55dbec508578 in invokeDtor clang/lib/AST/Interp/InterpBlock.h:79:7
    #3 0x55dbec508578 in clang::interp::Program::~Program() clang/lib/AST/Interp/Program.h:55:19
    #4 0x55dbec50657a in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5
    #5 0x55dbec50657a in std::__msan::unique_ptr<clang::interp::Program, std::__msan::default_delete<clang::interp::Program>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7
    #6 0x55dbec5035a1 in clang::interp::Context::~Context() clang/lib/AST/Interp/Context.cpp:27:22
    #7 0x55dbebec1daa in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5
    #8 0x55dbebec1daa in std::__msan::unique_ptr<clang::interp::Context, std::__msan::default_delete<clang::interp::Context>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7
    #9 0x55dbebe285f9 in clang::ASTContext::~ASTContext() clang/lib/AST/ASTContext.cpp:1038:40
    #10 0x55dbe941ff13 in llvm::RefCountedBase<clang::ASTContext>::Release() const llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:101:7
    #11 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:159:38
    #12 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:224:7
    #13 0x55dbe94353ef in ~IntrusiveRefCntPtr llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:191:27
    #14 0x55dbe94353ef in clang::CompilerInstance::setASTContext(clang::ASTContext*) clang/lib/Frontend/CompilerInstance.cpp:178:3
    #15 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8
    #16 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11
    #17 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25
    #18 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15
    #19 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12
    #20 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12
    #21 0x7f9be07fa632 in __libc_start_main
    #22 0x55dbe6a702e9 in _start

  Member fields were destroyed
    #0 0x55dbe6a7da5d in __sanitizer_dtor_callback_fields compiler-rt/lib/msan/msan_interceptors.cpp:949:5
    #1 0x55dbec5094ac in ~SmallVectorImpl llvm/include/llvm/ADT/SmallVector.h:479:7
    #2 0x55dbec5094ac in ~SmallVectorImpl llvm/include/llvm/ADT/SmallVector.h:612:3
    #3 0x55dbec5094ac in llvm::SmallVector<clang::interp::Record::Base, 8u>::~SmallVector() llvm/include/llvm/ADT/SmallVector.h:1207:3
    #4 0x55dbec508e79 in clang::interp::Record::~Record() clang/lib/AST/Interp/Record.h:24:7
    #5 0x55dbec508612 in clang::interp::Program::~Program() clang/lib/AST/Interp/Program.h:49:26
    #6 0x55dbec50657a in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5
    #7 0x55dbec50657a in std::__msan::unique_ptr<clang::interp::Program, std::__msan::default_delete<clang::interp::Program>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7
    #8 0x55dbec5035a1 in clang::interp::Context::~Context() clang/lib/AST/Interp/Context.cpp:27:22
    #9 0x55dbebec1daa in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5
    #10 0x55dbebec1daa in std::__msan::unique_ptr<clang::interp::Context, std::__msan::default_delete<clang::interp::Context>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7
    #11 0x55dbebe285f9 in clang::ASTContext::~ASTContext() clang/lib/AST/ASTContext.cpp:1038:40
    #12 0x55dbe941ff13 in llvm::RefCountedBase<clang::ASTContext>::Release() const llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:101:7
    #13 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:159:38
    #14 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:224:7
    #15 0x55dbe94353ef in ~IntrusiveRefCntPtr llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:191:27
    #16 0x55dbe94353ef in clang::CompilerInstance::setASTContext(clang::ASTContext*) clang/lib/Frontend/CompilerInstance.cpp:178:3
    #17 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8
    #18 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11
    #19 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25
    #20 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15
    #21 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12
    #22 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12
    #23 0x7f9be07fa632 in __libc_start_main
    #24 0x55dbe6a702e9 in _start
keryell pushed a commit that referenced this issue Jan 4, 2023
@yonghong-song
[clang][Sema] Fix a clang crash with btf_type_tag
2f047b5 
For the following program,
  $ cat t.c
  struct t {
   int (__attribute__((btf_type_tag("rcu"))) *f)();
   int a;
  };
  int foo(struct t *arg) {
    return arg->a;
  }
Compiling with 'clang -g -O2 -S t.c' will cause a failure like below:
  clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc):
         Assertion `Chunk.Kind == DeclaratorChunk::Paren' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  ......
  #5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5)
  #6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
  #7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456)
  #8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
  #9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
  ......

The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example,
the TypeLoc is
  BTFTagAttributedType 0x88614e0 'int  btf_type_tag(rcu)()' sugar
  |-ParenType 0x8861480 'int ()' sugar
  | `-FunctionNoProtoType 0x8861450 'int ()' cdecl
  |   `-BuiltinType 0x87fd500 'int'
while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and
this will cause later assertion.

To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in
GetTypeSourceInfoForDeclarator().

Differential Revision: https://reviews.llvm.org/D136807
Ralender pushed a commit to Ralender/sycl that referenced this issue Jun 9, 2023
@rorth
[sanitizer_common] Don't intercept __tls_get_addr on Solaris
951cf65 
When building/testing ASan inside the GCC tree on Solaris while using GNU
`ld` instead of Solaris `ld`, a large number of tests SEGVs on both sparc
and x86 like this:

  Thread 2 received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 1 (LWP 1)]
  0xfe014cfc in __sanitizer::atomic_load<__sanitizer::atomic_uintptr_t>
(a=0xfc602a58, mo=__sanitizer::memory_order_acquire) at
sanitizer_common/sanitizer_atomic_clang_x86.h:46
  46	      v = a->val_dont_use;
  1: x/i $pc
  => 0xfe014cfc
<_ZN11__sanitizer11atomic_loadINS_16atomic_uintptr_tEEENT_4TypeEPVKS2_NS_12memory_orderE+62>:
mov (%eax),%eax
  (gdb) bt
  #0 0xfe014cfc in __sanitizer::atomic_load<__sanitizer::atomic_uintptr_t>
(a=0xfc602a58, mo=__sanitizer::memory_order_acquire) at
sanitizer_common/sanitizer_atomic_clang_x86.h:46
  #1 0xfe0bd1d7 in __sanitizer::DTLS_NextBlock (cur=0xfc602a58) at
sanitizer_common/sanitizer_tls_get_addr.cpp:53
  triSYCL#2 0xfe0bd319 in __sanitizer::DTLS_Find (id=1) at
sanitizer_common/sanitizer_tls_get_addr.cpp:77
  triSYCL#3 0xfe0bd466 in __sanitizer::DTLS_on_tls_get_addr (arg_void=0xfeffd068,
res=0xfe602a18, static_tls_begin=0, static_tls_end=0) at
sanitizer_common/sanitizer_tls_get_addr.cpp:116
  triSYCL#4 0xfe063f81 in __interceptor___tls_get_addr (arg=0xfeffd068) at
sanitizer_common/sanitizer_common_interceptors.inc:5501
  triSYCL#5 0xfe0a3054 in __sanitizer::CollectStaticTlsBlocks (info=0xfeffd108,
size=40, data=0xfeffd16c) at
sanitizer_common/sanitizer_linux_libcdep.cpp:366
  triSYCL#6  0xfe6ba9fa in dl_iterate_phdr () from /usr/lib/ld.so.1
  triSYCL#7 0xfe0a3132 in __sanitizer::GetStaticTlsBoundary (addr=0xfe608020,
size=0xfeffd244, align=0xfeffd1b0) at
sanitizer_common/sanitizer_linux_libcdep.cpp:382
  triSYCL#8 0xfe0a33f7 in __sanitizer::GetTls (addr=0xfe608020, size=0xfeffd244)
at sanitizer_common/sanitizer_linux_libcdep.cpp:482
  triSYCL#9 0xfe0a34b1 in __sanitizer::GetThreadStackAndTls (main=true,
stk_addr=0xfe608010, stk_size=0xfeffd240, tls_addr=0xfe608020,
tls_size=0xfeffd244) at sanitizer_common/sanitizer_linux_libcdep.cpp:565

The address being accessed is unmapped.  However, even when the tests
`PASS` with Solaris `ld`, `ASAN_OPTIONS=verbosity=2` shows

  ==6582==__tls_get_addr: Can't guess glibc version

Given that that the code is stricly `glibc`-specific according to
`sanitizer_tls_get_addr.h`, there seems little point in using the
interceptor on non-`glibc` targets.

That's what this patch does.  Tested on `i386-pc-solaris2.11` and
`sparc-sun-solaris2.11` inside the GCC tree.

Differential Revision: https://reviews.llvm.org/D141385
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@agozillon