- Feb 10, 2022
-
-
Evgenii Stepanov authored
Summary: This is neccessary to support solaris/sparc9 where some userspace addresses have all top bits set, as well as, potentially, kernel memory on aarch64. This change does not update the compiler side (HWASan IR pass) which needs to be done separately for the affected targets. Reviewers: ro, vitalybuka Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D91827
-
Johannes Doerfert authored
New users might want to check bins without a load or store instruction at hand. Since we use those instructions only to find the offset and size of the access anyway, we can expose an offset and size interface to the outside world as well. This commit mainly moves code around and exposes a class (OffsetAndSize) as well as a method forallInterferingAccesses in AAPointerInfo. Differential Revision: https://reviews.llvm.org/D119249
-
Johannes Doerfert authored
The oversight caused us to ignore call sites that are effectively dead when we computed reachability (or more precise the call edges of a function). The problem is that loads in the readonly callee might depend on stores prior to the callee. If we do not track the call edge we mistakenly assumed the store before the call cannot reach the load. The problem is nicely visible in: `llvm/test/Transforms/Attributor/ArgumentPromotion/basictest.ll` Caused by D118673. Fixes https://github.com/llvm/llvm-project/issues/53726
-
Johannes Doerfert authored
When we privatize a pointer (~argument promotion) we introduce new private allocas as replacement. These need to be placed in the alloca address space as later passes cannot properly deal with them otherwise. Fixes https://github.com/llvm/llvm-project/issues/53725
-
Vitaly Buka authored
#53721 suggests that it should work after https://reviews.llvm.org/D119461
-
Krzysztof Drewniak authored
Having clarified that executing the SerializeToHsaco pass can depend on a ROCm installation, switch from calling lld as a library to using the copy of lld guaranteed to be included in a ROCm install. This removes the workaround introduced in D119277 Reviewed By: whchung Differential Revision: https://reviews.llvm.org/D119463
-
Peter Klausler authored
The second argument to the ASSOCIATED intrinsic must be a valid pointer or target. The test for this property only checked the last symbol in a data-reference, but any symbol in the reference with the POINTER or TARGET attribute will do. Differential Revision: https://reviews.llvm.org/D119450
-
Kirill Bobyrev authored
This prevents matching of defaulted comparison operators. Resolves: https://github.com/llvm/llvm-project/issues/53355 Author: Febbe (Fabian Keßler)
-
Nikolas Klauser authored
Add vector<bool>::reference::operator(bool) const Reviewed By: Quuxplusone, ldionne, #libc Spies: BRevzin, libcxx-commits Differential Revision: https://reviews.llvm.org/D117736
-
Michael Jones authored
the vector class, due to being dynamically resized, needs malloc. This fixes the build so that it only includes it when malloc should be available. Differential Revision: https://reviews.llvm.org/D119464
-
Michał Górny authored
Fix passing the port and IP address with the wrong endianness in get_sock_peer_name() that causes the connect() to fail inside without an outgoing network interface (it's trying to connect to 1.0.0.127 instead of 127.0.0.1). Differential Revision: https://reviews.llvm.org/D119461
-
Shilei Tian authored
This patch refines the logic to determine grid size as previous method can escape the check of whether `CudaBlocksPerGrid` could be greater than the actual hardware limit. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D119311
-
Adrian Prantl authored
to work around build failure introduced in https://reviews.llvm.org/D119036
-
Michael Jones authored
Add a basic implementation of the vector class for use internally to LLVM-libc. Reviewed By: sivachandra Differential Revision: https://reviews.llvm.org/D118954
-
Simon Pilgrim authored
-
Greg Clayton authored
This mainly affects Darwin targets (macOS, iOS, tvOS and watchOS) when these targets don't use dSYM files and the debug info was in the .o files. All modules, including the .o files that are loaded by the debug maps, were in the global module list. This was great because it allows us to see each .o file and how much it contributes. There were virtual functions on the SymbolFile class to fetch the symtab/debug info parse and index times, and also the total debug info size. So the main executable would add all of the .o file's stats together and report them as its own data. Then the "totalDebugInfoSize" and many other "totalXXX" top level totals were all being added together. This stems from the fact that my original patch only emitted the modules for a target at the start of the patch, but as comments from the reviews came in, we switched to emitting all of the modules from the global module list. So this patch fixes it so when we have a SymbolFileDWARFDebugMap that loads .o files, the main executable will have no debug info size or symtab/debug info parse/index times, but each .o file will have its own data as a separate module. Also, to be able to tell when/if we have a dSYM file I have added a "symbolFilePath" if the SymbolFile for the main modules path doesn't match that of the main executable. We also include a "symbolFileModuleIdentifiers" key in each module if the module does have multiple lldb_private::Module objects that contain debug info so that you can track down the information for a module and add up the contributions of all of the .o files. Tests were added that are labeled with @skipUnlessDarwin and @no_debug_info_test that test all of this functionality so it doesn't regress. For a module with a dSYM file, we can see the "symbolFilePath" is included: ``` "modules": [ { "debugInfoByteSize": 1070, "debugInfoIndexLoadedFromCache": false, "debugInfoIndexSavedToCache": false, "debugInfoIndexTime": 0, "debugInfoParseTime": 0, "identifier": 4873280600, "path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_dsym_binary_has_symfile_in_stats/a.out", "symbolFilePath": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_dsym_binary_has_symfile_in_stats/a.out.dSYM/Contents/Resources/DWARF/a.out", "symbolTableIndexTime": 7.9999999999999996e-06, "symbolTableLoadedFromCache": false, "symbolTableParseTime": 7.8999999999999996e-05, "symbolTableSavedToCache": false, "triple": "arm64-apple-macosx12.0.0", "uuid": "E1F7D85B-3A42-321E-BF0D-29B103F5F2E3" }, ``` And for the DWARF in .o file case we can see the "symbolFileModuleIdentifiers" in the executable's module stats: ``` "modules": [ { "debugInfoByteSize": 0, "debugInfoIndexLoadedFromCache": false, "debugInfoIndexSavedToCache": false, "debugInfoIndexTime": 0, "debugInfoParseTime": 0, "identifier": 4603526968, "path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_no_dsym_binary_has_symfile_identifiers_in_stats/a.out", "symbolFileModuleIdentifiers": [ 4604429832 ], "symbolTableIndexTime": 7.9999999999999996e-06, "symbolTableLoadedFromCache": false, "symbolTableParseTime": 0.000112, "symbolTableSavedToCache": false, "triple": "arm64-apple-macosx12.0.0", "uuid": "57008BF5-A726-3DE9-B1BF-3A9AD3EE8569" }, ``` And the .o file for 4604429832 looks like: ``` { "debugInfoByteSize": 1028, "debugInfoIndexLoadedFromCache": false, "debugInfoIndexSavedToCache": false, "debugInfoIndexTime": 0, "debugInfoParseTime": 6.0999999999999999e-05, "identifier": 4604429832, "path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_no_dsym_binary_has_symfile_identifiers_in_stats/main.o", "symbolTableIndexTime": 0, "symbolTableLoadedFromCache": false, "symbolTableParseTime": 0, "symbolTableSavedToCache": false, "triple": "arm64-apple-macosx" } ``` Differential Revision: https://reviews.llvm.org/D119400
-
Renato Golin authored
-
LLVM GN Syncbot authored
-
Krzysztof Drewniak authored
Reviewed By: whchung Differential Revision: https://reviews.llvm.org/D119455
-
Peter Klausler authored
Fortran allows forward references to derived types, including function results that are typed in a prefix of a FUNCTION statement. If a type is defined in the body of the function, a reference to that type from a prefix on the FUNCTION statement must resolve to the local symbol, even and especially when that type shadows one from the host scope. The solution is to defer the processing of that type until the end of the function's specification part. But the language doesn't allow for forward references to other names in the prefix, so defer the processing of the type only when it is not an intrinsic type. The data structures in name resolution that track this information for functions needed to become a stack in order to make this work, since functions can contain interfaces that are functions. Differential Revision: https://reviews.llvm.org/D119448
-
Yuanfang Chen authored
The introduction and some examples are on this page: https://devblogs.microsoft.com/cppblog/announcing-jmc-stepping-in-visual-studio/ The `/JMC` flag enables these instrumentations: - Insert at the beginning of every function immediately after the prologue with a call to `void __fastcall __CheckForDebuggerJustMyCode(unsigned char *JMC_flag)`. The argument for `__CheckForDebuggerJustMyCode` is the address of a boolean global variable (the global variable is initialized to 1) with the name convention `__<hash>_<filename>`. All such global variables are placed in the `.msvcjmc` section. - The `<hash>` part of `__<hash>_<filename>` has a one-to-one mapping with a directory path. MSVC uses some unknown hashing function. Here I used DJB. - Add a dummy/empty COMDAT function `__JustMyCode_Default`. - Add `/alternatename:__CheckForDebuggerJustMyCode=__JustMyCode_Default` link option via ".drectve" section. This is to prevent failure in case `__CheckForDebuggerJustMyCode` is not provided during linking. Implementation: All the instrumentations are implemented in an IR codegen pass. The pass is placed immediately before CodeGenPrepare pass. This is to not interfere with mid-end optimizations and make the instrumentation target-independent (I'm still working on an ELF port in a separate patch). Reviewed By: hans Differential Revision: https://reviews.llvm.org/D118428
-
Yuanfang Chen authored
Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D119301
-
Huihui Zhang authored
[AArch64][LoadStoreOptimizer] Ignore undef registers when checking rename register used between paired instructions. The content of undef registers are not used in meaningful ways, when checking if a rename register is used between paired instructions we should ignore undef registers. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D119305
-
Marek Kurdej authored
Fixes https://github.com/llvm/llvm-project/issues/44292. Fixes https://github.com/llvm/llvm-project/issues/45874. Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D119419
-
Nirvedh authored
If the result operand has a unit leading dim it is removed from all operands. Reviewed By: ThomasRaoux Differential Revision: https://reviews.llvm.org/D119206
-
Simon Pilgrim authored
-
Ivan Murashko authored
There is a clangd crash at `__memcmp_avx2_movbe`. Short problem description is below. The method `HeaderIncludes::addExistingInclude` stores `Include` objects by reference at 2 places: `ExistingIncludes` (primary storage) and `IncludesByPriority` (pointer to the object's location at ExistingIncludes). `ExistingIncludes` is a map where value is a `SmallVector`. A new element is inserted by `push_back`. The operation might do resize. As result pointers stored at `IncludesByPriority` might become invalid. Typical stack trace ``` frame #0: 0x00007f11460dcd94 libc.so.6`__memcmp_avx2_movbe + 308 frame #1: 0x00000000004782b8 clangd`llvm::StringRef::compareMemory(Lhs=" \"t2.h\"", Rhs="", Length=6) at StringRef.h:76:22 frame #2: 0x0000000000701253 clangd`llvm::StringRef::compare(this=0x0000 7f10de7d8610, RHS=(Data = "", Length = 7166742329480737377)) const at String Ref.h:206:34 * frame #3: 0x00000000007603ab clangd`llvm::operator<(llvm::StringRef, llv m::StringRef)(LHS=(Data = "\"t2.h\"", Length = 6), RHS=(Data = "", Length = 7166742329480737377)) at StringRef.h:907:23 frame #4: 0x0000000002d0ad9f clangd`clang::tooling::HeaderIncludes::inse rt(this=0x00007f10de7fb1a0, IncludeName=(Data = "t2.h\"", Length = 4), IsAng led=false) const at HeaderIncludes.cpp:365:22 frame #5: 0x00000000012ebfdd clangd`clang::clangd::IncludeInserter::inse rt(this=0x00007f10de7fb148, VerbatimHeader=(Data = "\"t2.h\"", Length = 6)) const at Headers.cpp:262:70 ``` A unit test test for the crash was created (`HeaderIncludesTest.RepeatedIncludes`). The proposed solution is to use std::list instead of llvm::SmallVector Test Plan ``` ./tools/clang/unittests/Tooling/ToolingTests --gtest_filter=HeaderIncludesTest.RepeatedIncludes ``` Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D118755
-
Craig Topper authored
We can lower a vector splice to a vslidedown and a vslideup. The majority of the matching code here came from X86's code for matching PALIGNR and VPALIGND/Q. The slidedown and slideup lowering don't really require it to be concatenation, but it happened to be an interesting pattern with existing analysis code I could use. This helps with cases where the scalar loop optimizer forwarded a load result from a previous loop iteration. For example, this happens if the loop uses x[i] and x[i+1] on the same iteration. The scalar optimizer will forward x[i+1] load from the previous loop to satisfy x[i] on this loop. When this get vectorized it results in one element of a vector being forwarded from the previous loop to be concatenated with elements loaded on this iteration. Whether that's more efficient than doing a shifted loaded or reloading the single scalar and using vslide1up is an interesting question. But that's not something the backend can help with. Reviewed By: khchen Differential Revision: https://reviews.llvm.org/D119039
-
Valentin Clement authored
This patch adds the lowering for the RETURN statement without alternate returns in the main program or in subroutine and functions. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D119429 Co-authored-by:
V Donaldson <vdonaldson@nvidia.com> Co-authored-by:
Eric Schweitz <eschweitz@nvidia.com> Co-authored-by:
Jean Perier <jperier@nvidia.com>
-
Valentin Clement authored
Replace the hardcoded attribute name with the constexpr StringRef defined in the FIROps.td file. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D119422
-
Craig Topper authored
The VLMaxSentinel is represented as TargetConstant, but that's included in isa<ConstantSDNode>. To keep constant VLs and VLMax separate as long as possible, use the X0 register during lowering and only convert to VLMaxSentinel during isel. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D118845
-
Hans Wennborg authored
we already accept "--target=". No reason to not accept "-target" too (that's the one I typically use for some reason). Differential revision: https://reviews.llvm.org/D119446
-
Paul Walker authored
These nodes provide an indirection that is not necessary because SVE has unpredicated add/sub instructions and there's no downside to using them for partial register operations. In fact, the test changes show that unifying how fixed-length and scalable vector add/sub are lowered enables better use of existing isel patterns. Differential Revision: https://reviews.llvm.org/D119355
-
Simon Pilgrim authored
Add smulo and umulo test coverage
-
Simon Pilgrim authored
Matches what we do in getThreeSrcCommuteCase. Fixes static analyzer out of bounds array access warning.
-
Arthur Eubanks authored
Previously memaccess-clobber.ll relied on both legacy PM-specific things like `-analyze` and MemoryDependenceAnalysis, which are both deprecated. This uses MemorySSA, which is the cool new thing that a bunch of passes have migrated to. Differential Revision: https://reviews.llvm.org/D119393
-
Craig Topper authored
Now that we pre-process SPLAT_VECTOR to VFMV_V_F_VL, these patterns handled scalable vectors and vectors converted from fixed. These are also used by vp.fma lowering.
-
Jordan Rupprecht authored
[libc++] Remove usage of `_LIBCPP_DEBUG` in `__comp_ref_type` and replace with `_LIBCPP_DEBUG_LEVEL` In libc++, checking specific `_LIBCPP_DEBUG_LEVEL` levels is used everywhere except in `comp_ref_type.h`. `_LIBCPP_DEBUG` is meant as a user-facing option, and internally libc++ should be checking the value of `_LIBCPP_DEBUG_LEVEL`. The definition of `std::__debug_less` doesn't need to be hidden behind the macro, we can unconditionally expose it. It will be unused by `__comp_ref_type` unless debug mode is enabled. This was suggested in D118940. Reviewed By: #libc, philnik, Quuxplusone, ldionne Differential Revision: https://reviews.llvm.org/D118950
-
Jordan Rupprecht authored
b07b5bd7 adds a use of `__comp_ref_type.h` to `std::min`. When libc++ is built with `-D_LIBCPP_DEBUG=0`, this enables `std::__debug_less`, which is only marked constexpr after c++17. `std::min` itself is marked as being `constexpr` as of c++14, so by extension, `std::__debug_less` should also be marked `constexpr` for the same versions so that `std::min` can use it. This change lowers the guard from `> 17` to `> 11`. Reproducer in godbolt: https://godbolt.org/z/ans3TGsj8 ``` constexpr int x() { return std::min<int>({1, 2, 3, 4}); } static_assert(x() == 1); ``` Reviewed By: #libc, philnik, Quuxplusone, ldionne Differential Revision: https://reviews.llvm.org/D118940
-
Mark de Wever authored
This avoids using an libc++ internal macro in our tests. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D119352
-