LLVM and SPIRV-LLVM-Translator pulldown (WW37) #41
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a nodeduplicate COMDAT group contains a weak symbol, choose a non-weak symbol (or one of the weak ones) rather than reporting an error. This should address issue PR51394. With the current IR representation, a generic comdat nodeduplicate semantics is not representable for LTO. In the linker, sections and symbols are separate concepts. A dropped weak symbol does not force the defining input section to be dropped as well (though it can be collected by GC). In the IR, when a weak linkage symbol is dropped, its associate section content is dropped as well. For InstrProfiling, which is where ran into this issue in PR51394, the deduplication semantic is a sufficient workaround. Differential Revision: https://reviews.llvm.org/D108689
Reviewed By: LuoYuanke Differential Revision: https://reviews.llvm.org/D105799
Change pass-by-const-ref to pass-by-value as objects are recreated due to custom up-/down-casting anwyway.
A new LLVM specific TAG DW_TAG_LLVM_annotation is added.
The name is suggested by Paul Robinson ([1]).
Currently, this tag is used to output __attribute__((btf_tag("string")))
annotations in dwarf. The following is an example for a global
variable with two btf_tag attributes:
0x0000002a: DW_TAG_variable
DW_AT_name ("g1")
DW_AT_type (0x00000052 "int")
DW_AT_external (true)
DW_AT_decl_file ("/tmp/home/yhs/work/tests/llvm/btf_tag/t.c")
DW_AT_decl_line (8)
DW_AT_location (DW_OP_addr 0x0)
0x0000003f: DW_TAG_LLVM_annotation
DW_AT_name ("btf_tag")
DW_AT_const_value ("tag1")
0x00000048: DW_TAG_LLVM_annotation
DW_AT_name ("btf_tag")
DW_AT_const_value ("tag2")
0x00000051: NULL
In the future, DW_TAG_LLVM_annotation may encode other type
of non-string const value.
[1] https://lists.llvm.org/pipermail/llvm-dev/2021-June/151250.html
Differential Revision: https://reviews.llvm.org/D106621
Analogous to the TSFlags for machine instructions, this patch introduces a bit vector for register classes to have target specific flags that become a tablegened value in TargetRegisterClass. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D108767
While initializing the LDS pointers within entry basic block of kernel(s), make sure that the entry basic block is split after alloca instructions. Reviewed By: rampitec Differential Revision: https://reviews.llvm.org/D108971
The current infrastructure in lib/Interpreter has a tool, clang-repl, very similar to clang-interpreter which also allows incremental compilation. This patch moves clang-interpreter as a test case and drops it as conditionally built example as we already have clang-repl in place. Differential revision: https://reviews.llvm.org/D107049
For a variable in a comdat nodeduplicate, its initializer may be significant. E.g. its content may be implicitly referenced by another comdat member (or required to parallel to another comdat member by the runtime when explicit section is used). We can clone it into an unnamed private linkage variable to preserve its content. This partially fixes PR51394 (Sony's proprietary linker using LTO): no error will be reported. This is partial because we do not guarantee the global variable order if the runtime has parallel section requirement. --- There is a similar issue for regular LTO, but unrelated to PR51394: with lib/LTO (using either ld.lld or LLVMgold.so), linking two modules with a weak function of the same name, can leave one weak profc and two private profd, due to lib/LTO's current deficiency that it mixes the two concepts together: comdat selection and symbol resolution. If the issue is considered important, we should suppress private profd for the weak+ regular LTO case. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D108879
This test sometimes triggers failures during build testing. For instance, see: https://lab.llvm.org/buildbot/#/builders/52/builds/10161, details: https://lab.llvm.org/buildbot/#/builders/52/builds/10161/steps/5/logs/FAIL__Clang__check-time-trace-sections_cpp . AFAICT the time between driver calling and checking its time tracker output is not guaranteed to be stable and small: ``` > head -2 check-time-trace-sections.cpp // RUN: %clangxx -S -ftime-trace -ftime-trace-granularity=0 -o %T/check-time-trace-sections %s // RUN: cat %T/check-time-trace-sections.json | %python %S/check-time-trace-sections.py > clang -S -ftime-trace -ftime-trace-granularity=0 -o /tmp/check check-time-trace-sections.cpp > cat /tmp/check.json | python check-time-trace-sections.py > sleep 10 > cat /tmp/check.json | python check-time-trace-sections.py 'beginningOfTime' should represent the absolute time when the process has started > ``` The attribute `beginningOfTime` was introduced here: https://reviews.llvm.org/D78030 One can change "10 sec" value to something longer, but I believe it's enough just to check that `beginningOfTime` exists and is not later than current time. Differential Revision: https://reviews.llvm.org/D108625
Temporarily remove breakpoints for the duration of vfork, in order to prevent them from triggering in the child process. Restore them once the server reports that vfork has finished and it is ready to resume execution. Differential Revision: https://reviews.llvm.org/D100267
Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D108973
The standard specifies that the form must be set to a default at the end of an open statement (C.7.4 point 2) where it was not specified. Only in the case of a pre-connected unit can the form be deferred until the first data transfer statement. Set back the default form setting in OpenStatementState::EndIoStatement that had been removed when deferring the pre-connected unit from setting in 199a623. Also return "UNDEFINED" instead of "UNKNOWN" to the FORM inquiry when the form was not yet specified as defined in 12.10.2.12. Related test: syntax 215a216. Differential Revision: https://reviews.llvm.org/D108990
Reviewed By: phosek, MaskRay Differential Revision: https://reviews.llvm.org/D108890
This reverts commit 319ce98 because it fails on various platforms.
This reverts commit 199344d. It caused regressions on arm, as reported by lldb-arm-ubuntu buildbot.
Add support to load/store i128 atomically. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D105612
Configure and use the TSFlags in TargetRegisterClass to have unique flags for VGPR and AGPR register classes. The vector register class queries like `hasVGPRs` will now become more efficient with just a bitwise operation. Reviewed By: rampitec Differential Revision: https://reviews.llvm.org/D108815
s/Uexpected/Unexpected.
SCEVPredicate has a friend declaration. The friend can technically call the protected destructor, so the warning is legitimate. Clang simply doesn't implement the friend check. Make the dtor virtual to fix the issue.
Temporarily remove breakpoints for the duration of vfork, in order to prevent them from triggering in the child process. Restore them once the server reports that vfork has finished and it is ready to resume execution. Differential Revision: https://reviews.llvm.org/D100267
Modifies OpenCL 3.0 optional core feature macro definitions so that they are set analogously in C++ for OpenCL 2021. This change aims to achieve compatibility between C++ for OpenCL 2021 and OpenCL 3.0. Differential Revision: https://reviews.llvm.org/D108704
This is a continuation of the review: https://reviews.llvm.org/D100181 Creates a new directory "libompd" under openmp. "TargetValue" provides operational access to the OpenMP runtime memory for OMPD APIs. With TargetValue, using "pointer" a user can do multiple operations from casting, dereferencing to accessing an element for structure. The member functions are designed to concatenate the operations that are needed to access values from structures. e.g., _a[6]->_b._c would read like : TValue(ctx, "_a").cast("A",2) .getArrayElement(6).access("_b").cast("B").access("_c") For example: If you have a pointer "ThreadHandle" of a running program then you can access/retrieve "threadID" from the memory using TargetValue as below. TValue(context, thread_handle->th) /*__kmp_threads[t]->th*/ .cast("kmp_base_info_t") .access("th_info") /*__kmp_threads[t]->th.th_info*/ .cast("kmp_desc_t") .access("ds") /*__kmp_threads[t]->th.th_info.ds*/ .cast("kmp_desc_base_t") .access("ds_thread") /*__kmp_threads[t]->th.th_info.ds.ds_thread*/ .cast("kmp_thread_t") .getRawValue(thread_id, 1); Reviewed By: @hbae Differential Revision: https://reviews.llvm.org/D100182
Original commit message:" The current infrastructure in lib/Interpreter has a tool, clang-repl, very similar to clang-interpreter which also allows incremental compilation. This patch moves clang-interpreter as a test case and drops it as conditionally built example as we already have clang-repl in place. Differential revision: https://reviews.llvm.org/D107049 " This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0 which may be a feature request for the jit infrastructure. Also, adds a missing build system dependency to the orc jit.
nvlink does not support linking of cubin files archived in an archive. This tool extracts all the cubin files in the given device specific archive and pass them to nvlink. It is required for linking static device libraries for nvptx. Reviewed By: ye-luo Differential Revision: https://reviews.llvm.org/D108291
…/sve-intrinsics.ll
…/AArch64/sve-intrinsics.ll" This reverts commit aeb2bd6.
…/sve-intrinsics.ll
Deserializing from an SPSSequence<char> to an an ArrayRef<char> will point the ArrayRef<char> at the input buffer.
…alls. All ExecutorProcessControl subclasses must provide a JITLinkMemoryManager object that can be used to allocate memory in the executor process. The EPCGenericJITLinkMemoryManager class provides an off-the-shelf JITLinkMemoryManager implementation for JITs that do not need (or cannot provide) a specialized JITLinkMemoryManager implementation. This simplifies the process of creating new ExecutorProcessControl implementations.
This should fix the build issues in https://lab.llvm.org/buildbot#builders/171/builds/3149.
Build should be fixed by llvm/llvm-project@9d22754389 This reverts commit df052e1. Differential Revision: https://reviews.llvm.org/D109181
Recent changes in the DPC++ compiler (intel#3929) allow to disregard the `sycldevice` component from the target triple in command lines. From there on, IR files for the Translator tests should be produced using the simplified target triple. Clean up the existing tests to match this change. Signed-off-by: Artem Gindinson <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@0a1f59c
VLAs were translated in section where non-instruction SPIR-V values are translated. Hovewer translation of them produce LLVM IR instructions. This patch moves translation of VLAs to the proper place where other instructions are created, so the placeholder creation logic also works for them. This fixes the case when VLA used in complex control flow graph caused producing of invalid LLVM module during reverse translation. Original commit: KhronosGroup/SPIRV-LLVM-Translator@89b319e
https://reviews.llvm.org/D88645 introduces additional parameter to var/ptr/global annotation instruction, which can be set by clang::annotation attribute that has variadic constant expression argument. Right now we can't translate it properly and an extension is being discussed, but yet we need a W/A for this. As a W/A the current patch makes this argument (in case if it is const int) be translatable as a string put in UserSemantic decorations, so the IL flow is looking like this: Annotation in source-code: [[clang::annotate("custom", 30, 60)]] int *Var; LLVM IR before: @.str = private unnamed_addr constant [7 x i8] c"custom\00" @.args = private unnamed_addr constant { i32, i32 } { i32 30, i32 60 } // ... call void @llvm.var.annotation(i8* ..., i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i32 0, i32 0), i8* ... , i32 ..., i8* bitcast ({ i32, i32 }* @.args to i8*)) // ... SPIR-V: Decorate %GEP% UserSemantic "custom: 30, 60" LLVM IR after: @3 = private unnamed_addr constant [15 x i8] c"custom: 30, 60\00" // ... call void @llvm.var.annotation(i8* ..., i8* getelementptr inbounds ( [15 x i8], [15 x i8]* @3, i32 0, i32 0), i8* ..., i32 ..., i8* undef) // ... As you see the annotation remains to be a string after the translation. It's done so because we wouldn't be able to distinguish [[clang::annotate("custom", 30, 60)]] from [[clang::annotate("custom, 30, 60")]] as they both would result in the same UserSemantic decoration. Also this patch brings a bit of refactoring of add Intel FPGA decoration functions, since their infrustructure can (and should) be reused here, solving an issue of incorrect allowed FPGA memory SPIR-V extensions processing. TODO: 1. Replace this W/A with an extension, when it's ready; 2. Global annotation instruction isn't handled properly yet, its handling requires even more refactoring, which I plan to do, when the extension is ready. Signed-off-by: Dmitry Sidorov <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@869f703
…return id Signed-off-by: Dmitry Sidorov <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@403a943
There is a patch to keep convergent attr during translation of OpControlBarrier to prevent optimization passes from making barrier calls control-dependent. Original commit: KhronosGroup/SPIRV-LLVM-Translator@4ccb1b2
|
/merge |
|
Mon Sep 13 07:28:19 UTC 2021 --- Merge failed with error: PR is not clean for merge. Please examine approval status or check status before merge. |
|
/merge |
|
Mon Sep 13 07:29:51 UTC 2021 --- Start to merge the commit into sycl branch. It will take several minutes. |
|
Mon Sep 13 07:32:55 UTC 2021 --- Merge the branch in this PR to base automatically. Will close the PR later. |
DoyleLi
pushed a commit
that referenced
this pull request
Nov 8, 2021
Motivation: At the moment it is hard to attribute a clangd crash to a specific request out of all in-flight requests that might be processed concurrently. So before we can act on production clangd crashes, we have to do quite some digging through the log tables populated by our in-house VSCode extension or sometimes even directly reach out to the affected developer. Having all the details needed to reproduce a crash printed alongside its stack trace has a potential to save us quite some time, that could better be spent on fixing the actual problems. Implementation approach: * introduce `ThreadCrashReporter` class that allows to set a temporary signal handler for the current thread * follow RAII pattern to simplify printing context for crashes occurring within a particular scope * hold `std::function` as a handler to allow capturing context to print * set local `ThreadCrashReporter` within `JSONTransport::loop()` to print request JSON for main thread crashes, and in `ASTWorker::run()` to print the file paths, arguments and contents for worker thread crashes `ThreadCrashReporter` currently allows only one active handler per thread, but the approach can be extended to support stacked handlers printing context incrementally. Example output for main thread crashes: ``` ... #15 0x00007f7ddc819493 __libc_start_main (/lib64/libc.so.6+0x23493) #16 0x000000000249775e _start (/home/emmablink/local/llvm-project/build/bin/clangd+0x249775e) Signalled while processing message: {"jsonrpc": "2.0", "method": "textDocument/didOpen", "params": {"textDocument": {"uri": "file:///home/emmablink/test.cpp", "languageId": "cpp", "version": 1, "text": "template <typename>\nclass Bar {\n Bar<int> *variables_to_modify;\n foo() {\n for (auto *c : *variables_to_modify)\n delete c;\n }\n};\n"}}} ``` Example output for AST worker crashes: ``` ... #41 0x00007fb18304c14a start_thread pthread_create.c:0:0 #42 0x00007fb181bfcdc3 clone (/lib64/libc.so.6+0xfcdc3) Signalled during AST action: Filename: test.cpp Directory: /home/emmablink Command Line: /usr/bin/clang -resource-dir=/data/users/emmablink/llvm-project/build/lib/clang/14.0.0 -- /home/emmablink/test.cpp Version: 1 Contents: template <typename> class Bar { Bar<int> *variables_to_modify; foo() { for (auto *c : *variables_to_modify) delete c; } }; ``` Testing: The unit test covers the thread-localitity and nesting aspects of `ThreadCrashReporter`. There might be way to set up a lit-based integration test that would spawn clangd, send a message to it, signal it immediately and check the standard output, but this might be prone to raceconditions. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D109506
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.