g #4
Merged
g #4
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
The maxf implementation of wmma elementwise op was incorrect as the operands of the select to check for Nan were swapped. Differential Revision: https://reviews.llvm.org/D127879
CONFLICT (content): Merge conflict in clang/lib/Sema/SemaDeclAttr.cpp CONFLICT (content): Merge conflict in clang/lib/Sema/ParsedAttr.cpp CONFLICT (content): Merge conflict in clang/include/clang/Basic/DiagnosticSemaKinds.td
The driver option -no-pie is preferred: Clang selects different crt*.o files, though the PIC one usually can replace the non-PIC one.
The only user that passed in a custom builder was passing in VPTransformState::Builder, which is the same as ILV::Builder.
Previously if the inliner split an SCC such that an empty one remained, the MLInlineAdvisor could potentially lose track of the EdgeCount if a subsequent CGSCC pass modified the calls of a function that was initially in the SCC pre-split. Saving the seen nodes in onPassEntry resolves this. Reviewed By: mtrofin Differential Revision: https://reviews.llvm.org/D127693
…fied We shouldn't assume that libunwind.so is available. Rather can defer the decision to the linker which defaults to libunwind.so, but if .so isn't available, it'd pick libunwind.a. Users can use -static-libgcc and -shared-libgcc to override this behavior and explicitly choose the version they want. Differential Revision: https://reviews.llvm.org/D127528
Add return values to converter functions to allow for better error handling when writing files. Also move the file writing code around to be easier to read. Reviewed By: sivachandra Differential Revision: https://reviews.llvm.org/D127773
This patch adds the entrypoint for printf. With this, building a "hello world" program with just LLVM-libc is possible. Reviewed By: sivachandra Differential Revision: https://reviews.llvm.org/D126831
Create a ninja target for running the LLDB target fuzzer. Currently the ninja target for the fuzzer will build the fuzzer without running it. This allows the fuzzer to be built and run. Differential revision: https://reviews.llvm.org/D127882
When querying the index during an ObjC protocol name lookup for code completion, we should only suggest ObjC protocols. Differential Revision: https://reviews.llvm.org/D127125
…lPTProcessTrace class We have two different "process trace" implementations: per thread and per core. As a way to simplify the collector who uses both, I'm creating a base abstract class that is used by these implementations. This effectively simplify a good chunk of code. Differential Revision: https://reviews.llvm.org/D125503
… buffer perf_event configuration We were setting some events to be written in the data buffer of the perf_event, but we don't need that. Besides that, we don't need the data buffer to be larger than 1, so we can reduce its size. Differential Revision: https://reviews.llvm.org/D125850
… context switch traces - Add collection of context switches per cpu grouped with the per-cpu intel pt traces. - Move the state handling from the interl pt trace class to the PerfEvent one. - Add support for stopping and enabling perf event groups. - Return context switch entries as part of the jLLDBTraceGetState response. - Move the triggers of whenever the process stopped or resumed. Now the will-resume notification is in a better location, which will ensure that we'll capture the instructions that will be executed. - Remove IntelPTSingleBufferTraceUP. The unique pointer was useless. - Add unit tests Differential Revision: https://reviews.llvm.org/D125897
…nd tsc information from lldb-server. - Add a warnings field in the jLLDBGetState response, for warnings to be delivered to the client for troubleshooting. This removes the need to silently log lldb-server's llvm::Errors and not expose them easily to the user - Simplify the tscPerfZeroConversion struct and schema. It used to extend a base abstract class, but I'm doubting that we'll ever add other conversion mechanisms because all modern kernels support perf zero. It is also the one who is supposed to work with the timestamps produced by the context switch trace, so expecting it is imperative. - Force tsc collection for cpu tracing. - Add a test checking that tscPerfZeroConversion is returned by the GetState request - Add a pre-check for cpu tracing that makes sure that perf zero values are available. Differential Revision: https://reviews.llvm.org/D125932
… perf conversion in the client - Add logging for when the live state of the process is refreshed - Move error handling of the live state refreshing to Trace from TraceIntelPT. This allows refreshing to fail either at the plug-in level or at the base class level. The error is cached and it can be gotten every time RefreshLiveProcessState is invoked. - Allow DoRefreshLiveProcessState to handle plugin-specific parameters. - Add some encapsulation to prevent TraceIntelPT from accessing variables belonging to Trace. Test done via logging: ``` (lldb) b main Breakpoint 1: where = a.out`main + 20 at main.cpp:27:20, address = 0x00000000004023d9 (lldb) r Process 2359706 launched: '/home/wallace/a.out' (x86_64) Process 2359706 stopped * thread #1, name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x00000000004023d9 a.out`main at main.cpp:27:20 24 }; 25 26 int main() { -> 27 std::vector<int> vvv; 28 for (int i = 0; i < 100000; i++) 29 vvv.push_back(i); 30 (lldb) process trace start (lldb) log enable lldb target -F(lldb) n Process 2359706 stopped * thread #1, name = 'a.out', stop reason = step over frame #0: 0x00000000004023e8 a.out`main at main.cpp:28:12 25 26 int main() { 27 std::vector<int> vvv; -> 28 for (int i = 0; i < 100000; i++) 29 vvv.push_back(i); 30 31 std::deque<int> dq1 = {1, 2, 3}; (lldb) thread trace dump instructions -c 2 -t Trace.cpp:RefreshLiveProcessState Trace::RefreshLiveProcessState invoked TraceIntelPT.cpp:DoRefreshLiveProcessState TraceIntelPT found tsc conversion information thread #1: tid = 2359706 a.out`std::vector<int, std::allocator<int>>::vector() + 26 at stl_vector.h:395:19 54: [tsc=unavailable] 0x0000000000403a7c retq ``` See the logging lines at the end of the dump. They indicate that refreshing happened and that perf conversion information was found. Differential Revision: https://reviews.llvm.org/D125943
This allows to set printAsJSON through the create function. Differential Revision: https://reviews.llvm.org/D127891
…nodes are different vector types. Currently in `combineVectorShuffle()`, we update the shuffle mask if either input vector comes from a scalar_to_vector, and we keep the respective input vectors in its permuted form by producing PPCISD::SCALAR_TO_VECTOR_PERMUTED. However, it is possible that we end up in a situation where both input vectors to the vector_shuffle are scalar_to_vector, and are different vector types. In situations like this, the shuffle mask is updated incorrectly as the current code assumes both scalar_to_vector inputs are the same vector type. This patch skips the combines for vector_shuffle if both input vectors are scalar_to_vector, and if they are of different vector types. A follow up patch will focus on fixing this issue afterwards, in order to correctly update the shuffle mask. Differential Revision: https://reviews.llvm.org/D127818
This adds information for DRs 126 through 146.
Several build bots are failing with surprising behavior, so it's less clear whether we do or don't implement this DR properly. https://lab.llvm.org/buildbot/#/builders/91/builds/10454 https://lab.llvm.org/buildbot/#/builders/109/builds/40668 https://lab.llvm.org/buildbot/#/builders/139/builds/23334
This reverts commit f3250da. This broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/19988 and likely others.
Differential Revision: https://reviews.llvm.org/D127827
When an unconnected unit number is used in a BACKSPACE statement with ERR=, IOSTAT=, &/or IOMSG= control specifiers, don't crash, but let the program deal with the error. Differential Revision: https://reviews.llvm.org/D127782
…e trace load and save :q! This diff is massive, but it's because it connects the client with lldb-server and also ensures that the postmortem case works. - Flatten the postmortem trace schema. The reason is that the schema has become quite complex due to the new multicore case, which defeats the original purpose of having a schema that could work for every trace plug-in. At this point, it's better that each trace plug-in defines it's own full schema. This means that the only common field is "type". -- Because of this new approach, I merged the "common" trace load and saving functionalities into the IntelPT one. This simplified the code quite a bit. If we eventually implement another trace plug-in, we can see then what we could reuse. -- The new schema, which is flattened, has now better comments and is parsed better. A change I did was to disallow hex addresses, because they are a bit error prone. I'm asking now to print the address in decimal. -- Renamed "intel" to "GenuineIntel" in the schema because that's what you see in /proc/cpuinfo. - Implemented reading the context switch trace data buffer. I had to do some refactors to do that cleanly. -- A major change that I did here was to simplify the perf_event circular buffer reading logic. It was too complex. Maybe the original Intel author had something different in mind. - Implemented all the necessary bits to read trace.json files with per-core data. - Implemented all the necessary bits to save to disk per-core trace session. - Added a test that ensures that parsing and saving to disk works. Differential Revision: https://reviews.llvm.org/D126015
Reviewed By: var-const, Mordante, #libc Spies: H-G-Hristov, sstefan1, libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D127130
Disable or canonicalize compiler options that are not relevant in explicit module builds, similar to what we already did for the modules cache path. This reduces uninteresting differences between command-lines, which is particularly useful if there is a tool that can cache the compilations. Differential Revision: https://reviews.llvm.org/D127883
A REWIND of a unit that's in the middle of a record due to a READ or WRITE statement with ADVANCE='NO' needs to reset the left tab limit so that the next transfer takes place at the beginning of the first record. Differential Revision: https://reviews.llvm.org/D127783
…pass The 'emit_c_wrappers' option in the FuncToLLVM conversion requests C interface wrappers to be emitted for every builtin function in the module. While this has been useful to bootstrap the interface, it is problematic in the longer term as it may unintentionally affect the functions that should retain their existing interface, e.g., libm functions obtained by lowering math operations (see D126964 for an example). Since D77314, we have a finer-grain control over interface generation via an attribute that avoids the problem entirely. Remove the 'emit_c_wrappers' option. Introduce the '-llvm-request-c-wrappers' pass that can be run in any pipeline that needs blanket emission of functions to annotate all builtin functions with the attribute before performing the usual lowering that accounts for the attribute. Reviewed By: chelini Differential Revision: https://reviews.llvm.org/D127952
In addition to division by zero, signed division also traps for SignedMin / -1. This was handled in isSafeToSpeculativelyExecute(), but not in Constant::canTrap().
We are still not ready to enable opaque pointers by default, so tests that use opaque pointers still need to have them enabled explicitly.
Factor out common code, in preparation of transitioning SPIRVWriter to the new PassManager. Original commit: KhronosGroup/SPIRV-LLVM-Translator@dc9e645
Update the SHA-1 of the SPIRV-Headers dependency to 5a121866927. Regenerate the header files using the newer spirv.hpp. The generated .h files had to be tweaked manually due to various internal additions. Original commit: KhronosGroup/SPIRV-LLVM-Translator@3f5e65d
LLVM: llvm/llvm-project@daf897d SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@3f5e65d
…or (4.7.6.9) (#5737) A simple fix for ensuring correct errc is thrown for an unassociated placeholder accessor (4.7.6.9) Note that this fix is not complete. It only addresses the most common cases. There are still cases where an unassociated placeholder accessor could get by undetected and crash in the kernel. Unfortunately, the fix for those cases is not trivial. I have the outlines of a fix, but it would be disruptive, too disruptive for such a low priority fix. I will open a ticket about it and discuss it with various stakeholders. Expanded testing to cover this here: intel/llvm-test-suite#890 Signed-off-by: Chris Perkins chris.perkins@intel.com
This PR aims to refactor cmake building system for imf SYCL device library. Previously, the source of SYCL fallback device library has pre-assumption that all functions in the same fallback .spv or .o file must reside in single .cpp file. The reason is we need to use sycl compiler to build .spv or .o file with following commands: clang++ -fsycl -fsycl-device-only -fno-sycl-use-bitcode t.cpp -o t.spv clang++ -fsycl -c -fsycl-targets="..." t.cpp -o t.o However, imf fallback sources broke the pre-assumptions, all implementations reside in multiple .cpp files. Current building have to deal with multiple tools, for spv building, we have to do following: use "clang++ -fsycl -fsycl-device-only -c -emit-llvm" to generate LLVM .bc file for each .cpp use "llvm-link" to link multiple LLVM .bc into one LLVM .bc file use "llvm-spirv" to convert the LLVM .bc to spirv file For .o file, the steps are more complicated, we need to do following: use "clang++ -fsycl -fsycl-device-only -c -emit-llvm" to generate LLVM.bc for each .cpp Use "llvm-link" to link multiple LLVM .bc into one LLVM .bc file the steps 1,2 must be done for all sycl targets supported use clang-offload-bunlder to bundle different sycl target's LLVM .bc to final .objet file Current solution has following drawbacks: Too complicated, too much unnecessary work which is to emulate the work of simple “clang++ -fsycl …” command. This makes cmake hard to understand and maintain. Too fragile, clang driver may change the detail steps of simple “clang++ -fsycl…” and each tool used currently may update their option and usage which may lead to imf libdevice building failure. The more tools we deal with, the more risk we are in. So, we decide to use following solution: For building imf fallback spv or object file, we first combine all required .cpp into a “full” .cpp and then use simple “clang++ -fsycl …” command to build it. We will create a “libdevice” folder in build/lib and save the full .cpp file there. All imf fallback device library code will be organized to avoid code conflict, duplicate. Signed-off-by: jinge90 ge.jin@intel.com
This commit removes OpenCL calls from the runtime, replacing them with the corresponding PI calls. This removes the dependency on the OpenCL library from the runtime library. Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
Signed-off-by: bb-sycl <bb-sycl@intel.com>
* [SYCL] Add inline to get_local_linear_id These changes make sycl::detail::get_local_linear_id and its specializations inline. Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com> Co-authored-by: Sergey Semenov <sergey.semenov@intel.com>
The joint_group_conflict test uses compiler flags for the test that are not recognized when running on Windows. As such, the test is marked as unsupported for Windows. Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
This PR is adds part of the CUDA-backend spec interop proposed in KhronosGroup/SYCL-Docs#197. The changes work with the CUDA CTS interop checks KhronosGroup/SYCL-CTS#336. This PR just adds the event interop. llvm-test-suite: intel/llvm-test-suite#1053
Fixed off-by-one error introduced in #6201 that would cause queue synchronization to synchronize all streams when no stream has been used. The code worked correctly, but this can in some cases impact performance.
DPC++ implementation has been renamed in Khronos SYCL-CTS project from Intel_SYCL to DPCPP. These instructions are outdated for 10 months already. Khronos SYCL-CTS README file provides updated instructions and this guide already refers to the README file, so removed part duplicates the information. Fixed linked to the README section with the test build build and run instructions.
This patch fix the casting of integer coordinates in image samplers. This solves #6285, allowing to re-enable the tests disabled in intel/llvm-test-suite#1052.
Uplift GPU RT version for Linux to 22.24.23453 Co-authored-by: GitHub Actions <actions@github.com>
…6242) * Make esimd implementation of fmod compatible with std::fmod
The driver option -f[no-]sycl-esimd-force-stateless-mem is added. -fsycl-esimd-force-stateless-mem enables the automatic conversion of stateful memory accesses via SYCL accessors or surface-index to stateless within ESIMD kernels. It also disables those ESIMD intrinsics that use stateful accesses that cannot be converted to stateless. -fsycl-esimd-force-stateless-mem defines the macro __ESIMD_FORCE_STATELESS_MEM to map the calls of ESIMD API using accessors to calls of API using pointers. It also passes a switch to sycl-post-link to signal it that it should ignore the buffer_t attribute and use svmptr_t. -fno-sycl-esimd-force-stateless-mem is used to tell the compiler not to convert stateful memory accesses to stateless. Default behavior. Draft of the design document/proposal for this change-set: #6187
raaiq1
pushed a commit
that referenced
this pull request
Jul 18, 2022
…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
raaiq1
pushed a commit
that referenced
this pull request
Jul 27, 2022
When we lower dynamic stack, we need to substract pattern `x15 << 4` from sp. Subtract instruction with arith shifted register(SUBXrs) can't refer to sp. So for now we need two extra mov like: ``` mov x0, sp sub x0, x0, x15, lsl #4 mov sp, x0 ``` If we want to refer to sp in subtract instruction like this: ``` sub sp, sp, x15, lsl #4 ``` We must use arith extended register version(SUBXrx). So in this patch when we find sub have sp operand on src0, try to select to SubXrx64. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D129932
raaiq1
pushed a commit
that referenced
this pull request
Nov 8, 2022
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
intel#17 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25
intel#18 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15
intel#19 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12
intel#20 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12
intel#21 0x7f9be07fa632 in __libc_start_main
intel#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
intel#17 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8
intel#18 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11
intel#19 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25
intel#20 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15
intel#21 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12
intel#22 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12
intel#23 0x7f9be07fa632 in __libc_start_main
intel#24 0x55dbe6a702e9 in _start
raaiq1
pushed a commit
that referenced
this pull request
Dec 20, 2022
The Assignment Tracking debug-info feature is outlined in this RFC: https://discourse.llvm.org/t/ rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir Add initial revision of assignment tracking analysis pass --------------------------------------------------------- This patch squashes five individually reviewed patches into one: #1 https://reviews.llvm.org/D136320 #2 https://reviews.llvm.org/D136321 #3 https://reviews.llvm.org/D136325 #4 https://reviews.llvm.org/D136331 #5 https://reviews.llvm.org/D136335 Patch #1 introduces 2 new files: AssignmentTrackingAnalysis.h and .cpp. The two subsequent patches modify those files only. Patch #4 plumbs the analysis into SelectionDAG, and patch #5 is a collection of tests for the analysis as a whole. The analysis was broken up into smaller chunks for review purposes but for the most part the tests were written using the whole analysis. It would be possible to break up the tests for patches #1 through #3 for the purpose of landing the patches seperately. However, most them would require an update for each patch. In addition, patch #4 - which connects the analysis to SelectionDAG - is required by all of the tests. If there is build-bot trouble, we might try a different landing sequence. Analysis problem and goal ------------------------- Variables values can be stored in memory, or available as SSA values, or both. Using the Assignment Tracking metadata, it's not possible to determine a variable location just by looking at a debug intrinsic in isolation. Instructions without any metadata can change the location of a variable. The meaning of dbg.assign intrinsics changes depending on whether there are linked instructions, and where they are relative to those instructions. So we need to analyse the IR and convert the embedded information into a form that SelectionDAG can consume to produce debug variable locations in MIR. The solution is a dataflow analysis which, aiming to maximise the memory location coverage for variables, outputs a mapping of instruction positions to variable location definitions. API usage --------- The analysis is named `AssignmentTrackingAnalysis`. It is added as a required pass for SelectionDAGISel when assignment tracking is enabled. The results of the analysis are exposed via `getResults` using the returned `const FunctionVarLocs *`'s const methods: const VarLocInfo *single_locs_begin() const; const VarLocInfo *single_locs_end() const; const VarLocInfo *locs_begin(const Instruction *Before) const; const VarLocInfo *locs_end(const Instruction *Before) const; void print(raw_ostream &OS, const Function &Fn) const; Debug intrinsics can be ignored after running the analysis. Instead, variable location definitions that occur between an instruction `Inst` and its predecessor (or block start) can be found by looping over the range: locs_begin(Inst), locs_end(Inst) Similarly, variables with a memory location that is valid for their lifetime can be iterated over using the range: single_locs_begin(), single_locs_end() Further detail -------------- For an explanation of the dataflow implementation and the integration with SelectionDAG, please see the reviews linked at the top of this commit message. Reviewed By: jmorse
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.