v #2
Merged
v #2
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
There's a dependency in AbstractTypeReader.inc that becomes an error after D127231.
Introduce RoundOp in the math dialect. The operation rounds the operand to the nearest integer value in floating-point format. RoundOp lowers to LLVM intrinsics 'llvm.intr.round' or as a function call to libm (round or roundf). Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D127286
Some of the passes that calculates tentative layout like LongJmp and Golang are expecting that only functions with valid index will be located in hot text section. But currently functions with valid profiles and not set index are breaking this logic, to fix this we can move the hasValidProfile() condition from AssignSections pass to ReorderFunctions. Vladislav Khmelevsky, Advanced Software Technology Lab, Huawei Differential Revision: https://reviews.llvm.org/D127223
This adds the papers from Feb 2022 (parts 1 and 2) and May 2022.
If u64 and uptr have the same size, then this will perform a shift by the bitwidth, which is UB. We only need this code if uptr is smaller than u64.
The paper titles were correct, but the document number and links were incorrect (typo'ed numbers).
…subreg liveness" Revert due to failed on LLVM_ENABLE_EXPENSIVE_CHECKS. This reverts commit cbe22c7.
Add expm1f function to bazel's build overlay. Reviewed By: gchatelet Differential Revision: https://reviews.llvm.org/D127298
Summary: This test was failing because of an implicit declaration of `printf` which isn't legal with newer C, causing it to fail. This patch just adds the necessary header.
Summary: We use the special section name `.llvm.offloading` to store device imagees in the host object file. We want these to be stripped by the linker as they are not used after linking so we use the `SHF_EXCLUDE` flag to instruct the linker to drop them. We used to do this for all sections that started with `.llvm.offloading` when we encoded metadata in the section name itself. Now we embed a special binary containing the metadata, we should only add the flag on this name specifically.
Based on D24038. LLVM has an @llvm.eh.dwarf.cfa intrinsic, used to lower the GCC-compatible __builtin_dwarf_cfa() builtin. Reviewed By: StephenFan Differential Revision: https://reviews.llvm.org/D126181
PLEASE DO NOT REVERT without careful consideration, and preferably prior discussion. cast<Ty>(X) is a "checked cast". Its entire purpose is explicitly documented (https://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast templates) as catching bad casts by asserting that the cast is valid. Unfortunately, in a recent rewrite of our casting infrastructure about three months back, these asserts got dropped. This is discussed in more detail on discourse in https://discourse.llvm.org/t/cast-x-is-broken-implications-and-proposal-to-address/63033. Differential Revision: https://reviews.llvm.org/D127231
The DexDeclareAddress command checks the value of a variable at a certain point in the debugged program, and saves that value to be used in other commands. If the value at that point is not a valid address however, it currently causes an error in Dexter when we try to cast it - this is fixed in this patch by catching the error and leaving the address value unresolved. Differential Revision: https://reviews.llvm.org/D127101
This patch adds codegen tests for operators on SVE VLS vector types
There's no need for the CoreturnStmt getChildren member to deal with the presence or absence of the operand member. All users already deal with null children. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D125542
The abstract state used in the data flow should not know anything about the instructions which produced the abstract states. Instead, when comparing two states, we can simply use information about the machine instr at that time. In the old design, basically any use of the instruction flags on the current (as opposed to a "Require" - aka upcoming state) would be a bug. We don't seem to actually have any such bugs, but we can make this much more obvious with code structure. Differential Revision: https://reviews.llvm.org/D126921
When e.g. a VR64 register is spilled to a stack slot requiring a long (20-bit) displacement, it is possible to use an FP opcode if the allocated phys reg allows it. This eliminates the use of a separate LAY instruction. Reviewed By: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D115406
To represent various loop levels within a nest, DA implements a special numbering scheme (see comment atop establishNestingLevels). The goal of this numbering scheme appears to be representing each unique loop distinctively by using as little memory as possible. This numbering scheme is simple when the source and destination of the dependence are in the same loop. In such cases the level is simply the depth of the loop in which src and dst reside. When the src and dst are not in the same loop, we could run into the following situation exposed by https://reviews.llvm.org/D71539. This patch fixes this by detecting such cases in checkSubscripts and treating them as non-linear/non-affine. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D110973
…ng to match with getTruncatedUSUBSAT Fixes some X86 PSUBUS regressions encountered in D127115 where the truncate was being replaced with a PACKSS/PACKUS before the fold got called again
Reviewed By: ThomasRaoux, hanchung Differential Revision: https://reviews.llvm.org/D127265
LUI+ADDIW always produces a simm32. This allows us to always fold it into a global offset. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D126729
…set. Add with immediates in the range [-4096, -2049] or [2048, 4095] get convert to two ADDIs. Teach RISCVMergeBaseOffset to recognize this pattern as well. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D126843
* Correct version of Python that is required for LLVM build * Fix several additional issues on the page
Preparation for the next major library version release Co-authored-by: Steffen Larsen <steffen.larsen@intel.com>
…6292) When using -fsanitize for spir64 targets, the driver would error out not allowing for compilation to move forward. -fsanitize is currently not supported for spir64 targets, but it is supported for host. Restrict the -fsanitize option to only be used for the Host compilation but also emit a diagnostic that -fsanitize is being ignored for the target compilation.
This commit makes the following changes. * Adds ext_intel_global_host_space in accordance with the sycl_ext_intel_usm_address_spaces extensions. * Deprecates ext_intel_host_device_space as it was misspelled and has been replaced by ext_intel_global_host_space. * Replaces uses of deprecated address spaces with ext_intel_global_device_space and ext_intel_global_host_space Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
This patch adds support for new FPGA attribute called [[intel::fpga_pipeline(N)]] that takes a Boolean parameter.
N can be a template parameter or constexpr. If the user didn't provide a parameter, the default value of N would
be 1, which implies enable pipelining.
This attribute can be applied to loops.
Example syntax:
// will disable loop pipelining
[[intel::fpga_pipeline(0)]]
for (int i = 0; i<N; ++i) {...}
LLVM IR:
When applied on a loop, the LLVM IR should be attached to llvm.loop metadata:
!{!"llvm.loop.intel.pipelining.enable", i32 N}
The value of the !"llvm.loop.intel.pipelining.enable" metadata is an i32 value that corresponds to the boolean parameter N.
A value of 0 is used for not pipelining the loop.
A value of 1 is used for pipelining the loop.
If the parameter is not given, value of N will be the default value 1, which implies we will pipeline the loop, and the IR will look like
!{!"llvm.loop.intel.pipelining.enable", i32 1}
Error Message:
We should emit an error when [[intel::initiation_interval(k)]] and [[intel::fpga_pipeline(0)]] are used together:
"error: initiation_interval and fpga_pipeline(0) attributes are not compatible"
We should emit an error when [[intel::max_concurrency(k)]] and [[intel::fpga_pipeline(0)]] are used together:
"error: max_concurrency and fpga_pipeline(0) attributes are not compatible"
Note: this basically performs very similar functionalities as [[intel::disable_loop_pipelining]], the plan is to deprecate disable_loop_pipelining in future releases and use [[intel::fpga_pipeline(n)]] instead.
Signed-off-by: Soumi Manna <soumi.manna@intel.com>
Introduces a new group type (root_group) representing all work-items executing a kernel, along with an associated kernel property that enables all work-items within a root_group to synchronize. Signed-off-by: John Pennycook <john.pennycook@intel.com>
…6244) In scope of improving thread-safety of the L0 plugin guard access to the following objects: pi_context, pi_device and pi_platform.
To provide support for math APIs and functions, not included in standard or <CL/sycl.hpp>. These math APIs are implemented in "imf" (Intel math functions) SYCL device library. All function names are decorated with __imf_ prefix. These functions may be further categorized into: * Different accuracy implementation for some math functions such as log, exp, cos, sin… * Type cast util functions for float, double, half, bfloat16 * Integer type util functions * SIMD util functions * Half type util functions * Bfloat16 type util functions This PR is 1st of a series of patches to add “imf” SYCL device library, it includes type cast util functions for float, double and integer type util functions. Signed-off-by: jinge90 ge.jin@intel.com
This PR adds a new aspect ext_oneapi_bfloat16 to allow a runtime check for if the device supports the bfloat16 floating point type. Only the CUDA implementation for checking if the device supports this aspect is added. Updated test: intel/llvm-test-suite#888
#6244 changed the L0 backend to use std::scoped_lock for various occasions. However, when building with MSVC some of the uses are done through copying. Since std::scoped_lock has its copy-constructor deleted this causes the build to fail. This commit changes this pattern to avoid the copy. Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
#5720 added a new specialization of get_info for info::device::ext_oneapi_bfloat16 but no Windows symbol was added to the dump file. This commit adds the missing symbol. Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
Increases minor version of the DPC++ runtime library in preparation for the next release. The new version is 5.7.0. Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
…sm (#6212) This patch refactors #1455 to avoid uses of deprecated `getPointerElementType` function. #1455 introduces the code that uses pointer type information to create a shadow copy of SYCL kernel object. The same can be achieved by applying `work-group` scope attribute the SYCL kernel object. Compiler allocates such object in local address space, so object is shared among all work-items in the work-group.
It is possible for a function declaration to be used by both @llvm.used and, e.g., a spir_func definition. Ensure that we don't attempt to erase such declarations when removing @llvm.used. Add a regression test. Most builds will hit an assertion in the first RUN line when the declaration is incorrectly erased.
Following the changes in #6256 this commit allows executable device binaries with ZEBIN format to be cached persistently. 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 queue interop. llvm-test-suite: intel/llvm-test-suite#1054
Improve performance of event synchronization by reducing the number of calls to cuStreamWaitEvent. This call is now skipped for the stream, the event is coming from. Also when enqueueing a new command with a dependency on a previous one an attempt to use the same stream will be made, so both can be waited on by only one call to cuStreamWaitEvent.
Due to a bug in OpenCL runtime the initial switch to blocking free was limited to GPU. Now that the bug is addressed, this patch removes this workaround.
Uplift GPU RT version for Linux to 22.23.23405 Co-authored-by: GitHub Actions <actions@github.com>
…on" (#6316) Signed-off-by: Vyacheslav N Klochkov <vyacheslav.n.klochkov@intel.com>
Signed-off-by: Arvind Sudarsanam <arvind.sudarsanam@intel.com>
…6182) This patch: 1) Adds esimd::set_kernel_properties API with the single supported property esimd::kernel_properties::use_double_grf, which lets compiler know that the calling kernel needs run in "double GRF" mode - more registers per thread at the expense of fewer H/W threads. This is temporary API until generic SYCL support for kernel properties is implemented: https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_kernel_properties.asciidoc 2) Provides "lowering" of this API by the new LowerESIMDKernelProps pass, which marks such kernels with "esimd-double-grf" function attribute, and invoke it from the sycl-post-link as a part of ESIMD lowering. 3) Implements new "dimension" of device code splitting in sycl-post-link: functions with and without "esimd-double-grf" attribute go to different modules. Device binary images resulting from "double-grf" modules are assigned the "isDoubleGRFEsimdImage" property 4) Updates runtime to add "-doubleGRF" option when JITting SPIRV binaries with the "isDoubleGRFEsimdImage" property. 5) Fixes sycl-post-link bug in ModuleSplitter.cpp:extractSubModule, where Function objects in the entry point list were not replaced with new Function objects in the cloned Module. This lead to corrupted symbol file in some cases. 6) Misc refactoring: - factor out call graph traversal from LowerESIMD into ESIMDUtils to use from multiple sources - fix entry group and module properties handling in the light of multi-dimensional splitting - improve internal interfaces to pass single ModuleDesc instead of Module + entry points + properties - limit entry points of a ModuleDesc to the ModuleDesc it was split from AOT compilation support is TBD. Signed-off-by: Konstantin S Bobrovsky <konstantin.s.bobrovsky@intel.com>
Uplift GPU RT version for Linux to 22.23.23405 Co-authored-by: GitHub Actions <actions@github.com>
Following on from #5412
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
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 5, 2022
Casting a pointer to a suitably large integral type by reinterpret-cast should result in the same value as by using the `__builtin_bit_cast()`. The compiler exploits this: https://godbolt.org/z/zMP3sG683 However, the analyzer does not bind the same symbolic value to these expressions, resulting in weird situations, such as failing equality checks and even results in crashes: https://godbolt.org/z/oeMP7cj8q Previously, in the `RegionStoreManager::getBinding()` even if `T` was non-null, we replaced it with `TVR->getValueType()` in case the `MR` was `TypedValueRegion`. It doesn't make much sense to auto-detect the type if the type is already given. By not doing the auto-detection, we would just do the right thing and perform the load by that type. This means that we will cast the value to that type. So, in this patch, I'm proposing to do auto-detection only if the type was null. Here is a snippet of code, annotated by the previous and new dump values. `LocAsInteger` should wrap the `SymRegion`, since we want to load the address as if it was an integer. In none of the following cases should type auto-detection be triggered, hence we should eventually reach an `evalCast()` to lazily cast the loaded value into that type. ```lang=C++ void LValueToRValueBitCast_dumps(void *p, char (*array)[8]) { clang_analyzer_dump(p); // remained: &SymRegion{reg_$0<void * p>} clang_analyzer_dump(array); // remained: {{&SymRegion{reg_$1<char (*)[8] array>} clang_analyzer_dump((unsigned long)p); // remained: {{&SymRegion{reg_$0<void * p>} [as 64 bit integer]}} clang_analyzer_dump(__builtin_bit_cast(unsigned long, p)); <--------- change #1 // previously: {{&SymRegion{reg_$0<void * p>}}} // now: {{&SymRegion{reg_$0<void * p>} [as 64 bit integer]}} clang_analyzer_dump((unsigned long)array); // remained: {{&SymRegion{reg_$1<char (*)[8] array>} [as 64 bit integer]}} clang_analyzer_dump(__builtin_bit_cast(unsigned long, array)); <--------- change #2 // previously: {{&SymRegion{reg_$1<char (*)[8] array>}}} // now: {{&SymRegion{reg_$1<char (*)[8] array>} [as 64 bit integer]}} } ``` Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D136603
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.