[pull] main from MaxMood96:main #148
Merged
Conversation
This file contains 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…ed pointers This patch allows MMA built-ins on PowerPC to accept restrict and volatile qualified pointers. Reviewed By: #powerpc, nemanjai Differential Revision: https://reviews.llvm.org/D106550
…tual-functions This requirement was introduced in the C++ Core guidelines in 2016: isocpp/CppCoreGuidelines@1894380 Then clang-tidy got updated to comply with the rule. However in 2019 this decision was reverted: isocpp/CppCoreGuidelines@5fdfb20 Therefore we need to apply the correct configuration to clang-tidy again. This also makes this cppcoreguidelines check consistent with the other 2 alias checks: hicpp-use-override and modernize-use-override. Additionally, add another RUN line to the unit test, to make sure cppcoreguidelines-explicit-virtual-functions is tested.
Add necessary typemaps for Lua bindings, together with some other files. Signed-off-by: Siger Yang <sigeryeung@gmail.com> Reviewed By: tammela Differential Revision: https://reviews.llvm.org/D108090
Add the vector transfer patterns and introduce the max transfer rank option on the codegen strategy. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D111635
This is the second part of p0388, dealing with overloads of list initialization to incomplete array types. It extends the handling added in D103088 to permit incomplete arrays. We have to record that the conversion involved an incomplete array, and so (re-add) a bit flag into the standard conversion sequence object. Comparing such conversion sequences requires knowing (a) the number of array elements initialized and (b) whether the initialization is of an incomplete array. This also updates the web page to indicate p0388 is implemented (there is no feature macro). Differential Revision: https://reviews.llvm.org/D103908
…ue [NFC]. The list of checked functions was incomplete in the description. Reviewed By: aaron.ballman, steakhal Differential Revision: https://reviews.llvm.org/D111623
This implements the new implicit conversion sequence to an incomplete (unbounded) array type. It is mostly Richard Smith's work, updated to trunk, testcases added and a few bugs fixed found in such testing. It is not a complete implementation of p0388. Differential Revision: https://reviews.llvm.org/D102645
Depends on D111135 Differential Revision: https://reviews.llvm.org/D111165
Add a switch to code gen strategy to disable/enable the vector transfer lowering and disable it by default. Differential Revision: https://reviews.llvm.org/D111647
This patch shifts the InstrRefBasedLDV class declaration to a header. Partially because it's already massive, but mostly so that I can start writing some unit tests for it. This patch also adds the boilerplate for said unit tests. Differential Revision: https://reviews.llvm.org/D110165
This has a couple of benefits: 1. It can sometimes fix clusters that got broken apart when the register allocator inserted a copy. 2. Post-RA scheduling does not have to worry about increasing register pressure, which in some cases gives it more freedom to reorder instructions. Testing on a collection of 10,000 graphics shaders compiled for gfx1010 showed: - The average length of each run of one or more load instructions increased by about 1%. - The number of runs of two or more load instructions increased by about 4%.
With the -early-live-intervals command line flag, TwoAddressInstructionPass::runOnMachineFunction would call MachineFunction::verify before returning to check the live intervals. But there was not much benefit to doing this since -verify-machineinstrs and LLVM_ENABLE_EXPENSIVE_CHECKS provide a more general way of scheduling machine verification after every pass. Also it caused problems on targets like Lanai which are marked as "not machine verifier clean", since verification would fail for known target-specific problems which are nothing to do with LiveIntervals. Differential Revision: https://reviews.llvm.org/D111618
This reverts commit 66e13c7. It was committed by accident.
This allows picking up on mingw triples that often use 'w64' instead of 'pc' as the vendor part. Differential Revision: https://reviews.llvm.org/D111297
While looking at LWG-2988 and P0558 it seems the issues were already implemented, but the synopsis wasn't updated. Some of the tests didn't validate the `noexcept` status. A few tests were missing completely: - `atomic_wait_explicit` - `atomic_notify_one` - `atomic_notify_all` Mark P0558 as complete, didn't investigate which version of libc++ first includes this. It seems the paper has been retroactively applied. I couldn't find whether this is correct, but looking at cppreference it seems intended. Completes - LWG-2988 Clause 32 cleanup missed one typename - P0558 Resolving atomic<T> named base class inconsistencies Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D103765
After CMake 3.18, we are able to limit the scope of the search to just Development.Module. Searching for Development will fail in situations where the Python libraries are not available. When possible, limit to just Development.Module. See: https://pybind11.readthedocs.io/en/stable/compiling.html#findpython-mode Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D111585
Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D111636
Some random changes that were hanging around in my workspace. Also, a tiny step towards creating a header file for the sparse utils lib. Reviewed By: bixia Differential Revision: https://reviews.llvm.org/D111589
This header was transitively included to provide the definition of __lc_ctype_ptr that we use on AIX, but that is fragile as it depends on the settings of compatibility macros, so we explicitly include it here to avoid that scenario. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D111239
These "dump" methods call into MachineOperand::dump, which doesn't exist with NDEBUG, thus we croak. Disable LiveDebugValues dump methods when NDEBUG is turned on to avoid this.
Fixes the tests added in D110852 for the debug iterators. Similar issues with hijacking `operator&` still exist, they will be addressed separately. Reviewed By: #libc, ldionne, Quuxplusone Differential Revision: https://reviews.llvm.org/D111564
Added support of a "--nvlink-path" option in clang-nvlink-wrapper which takes the path of nvlink binary. Static Device Library support for OpenMP (D105191) now searches for nvlink binary and passes its location via this option. In absence of this option, nvlink binary is searched in locations in PATH. Differential Revision: https://reviews.llvm.org/D111488
The operand of the second any_of in EnforceSmallerThan should be B not S like the FP code in the if below. Unfortunately, fixing that causes an infinite loop in the build of RISCV. So I've added a workaround for that as well. Fixes PR44768. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D111502
To get proper wrap-around behavior for the various kind parameter values of the optional COUNT= and COUNT_MAX= dummy arguments to the intrinsic subroutine SYSTEM_CLOCK, add an extra argument to the APIs for lowering to pass the integer kind of the actual argument. Avoid confusion by requiring that both actual arguments have the same kind when both are present. The results of the runtime functions remain std::int64_t and lowering should still convert them before storing to the actual argument variables. Rework the implementation a bit to accomodate the dynamic specification of the kind parameter, and to clean up some coding issues with preprocessing and templates. Use the kind of the COUNT=/COUNT_MAX= actual arguments to determine the clock's resolution, where possible, in conformance with other Fortran implementations. Differential Revision: https://reviews.llvm.org/D111281
This patch continues unblocking optimizations that are blocked by pseudo probe instrumentation. Not exactly like DbgIntrinsics, PseudoProbe intrinsic has other attributes (such as mayread, maywrite, mayhaveSideEffect) that can block optimizations. The issues fixed are: - Flipped default param of getFirstNonPHIOrDbg API to skip pseudo probes - Unblocked CSE by avoiding pseudo probe from clobbering memory SSA - Unblocked induction variable simpliciation - Allow empty loop deletion by treating probe intrinsic isDroppable - Some refactoring. Reviewed By: wenlei Differential Revision: https://reviews.llvm.org/D110847
…struct name resolution As reported in https://bugs.llvm.org/show_bug.cgi?id=48145, name resolution for omp critical construct was failing. This patch adds functionality to help that name resolution as well as implementation to catch name mismatches. The following semantic restrictions are therefore handled here: - If a name is specified on a critical directive, the same name must also be specified on the end critical directive - If no name appears on the critical directive, no name can appear on the end critical directive - If a name appears on either the start critical directive or the end critical directive Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D110502
…131) As noted in halide/Halide#6302, we hilariously fail to match PAVG if we even as much as look at it the wrong way. In this particular case, the problem stems from the fact that `PAVG` root (def) is a `trunc`, and leafs (uses) are `zext`'s, and InstCombine really loves to get rid of both of these, for example replace them with a bit mask. So we may not have said `zext`. Instead of checking for that + type match, i think we should rely on the actual active type, as per the knownbits. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D111571
2815ed5 added calls from ExecutorProcessControl::disconnect implementations to shut down the TaskDispatcher. We still need to call endSession to trigger disconnection though. This commit adds the necessary calls to the failing unit tests. https://llvm.org/PR52153
CUDA-11 headers rely on these NVCC builtins. Despite having `__nv` previx, those are *not* provided by libdevice. Differential Revision: https://reviews.llvm.org/D111665
…ire it. Another follow-up to 2815ed5 and 19b4e3c. For unit tests that don't use an ExecutionSession we need to call ExecutorProcessControl::disconnect directly to wait for the dispatcher to shut down. https://llvm.org/PR52153
Depends on D111609. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D111610
To reflect the fact that the new PM is the default now. Differential Revision: https://reviews.llvm.org/D111680
We shouldn't broadcast the original value when doing reduction. Instead we compute the reduction and then combine it with the original value. Differential Revision: https://reviews.llvm.org/D111666
This lets us reduce size of Node, similar to D111183 proposal. Depends on D111610. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D111612
Now StackDepotGet can retrive the stack in O(1). Depends on D111612. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D111613
An LLVM Flang build bot for Windows recently failed with a bunch of warning messages. None were from recent changes to the Fortran compiler; I suspect that a newer (or maybe older) version of MSVC was being used, or perhaps a different set of compiler options were temporarily applied to the build, since the buildbot status went back to green shortly thereafter. Most of the warnings looked bogus to me, but some are legitimate concerns and we might as well clean them up. This patch does so. Differential Revision: https://reviews.llvm.org/D111677
The Fortran 2018 standard defines the concept of simple contiguity in subclause 9.5.4 as a characteristic of arrays. So that scalars may also be used in contexts where simply contiguous arrays are allowed, f18 treats them as single-element arrays that are trivially contiguous. This patch documents this semantic extension and also adds comments to the predicate that implements the concept. Differential Revision: https://reviews.llvm.org/D111679
B/O/Z integer output editing must not reflect any sign extension of scalar output values. Add more size-dependent OutputInteger I/O APIs and kind instantiations of EditIntegerOutput. Differential Revision: https://reviews.llvm.org/D111678
Intel MPX failed to gain wide adoption and has been deprecated for a while. GCC 9.1 removed Intel MPX support. Linux kernel removed MPX in 2019. glibc 2.35 will remove the support.
GCC 9.1 removed Intel MPX support. Linux kernel removed MPX in 2019. glibc 2.35 will remove MPX. Our support is limited: we support assembling of bndmov but not bnd. Just remove it. Reviewed By: pengfei, skan Differential Revision: https://reviews.llvm.org/D111517
…zableInPlaceAnalysis Differential Revision: https://reviews.llvm.org/D111380
A recently added class constructor needs to be "explicit" to prevent it from being available for use as a conversion, which is breaking the MSVC build of flang.
…d and OpResult By doing so, it is not necessary to get the OpOperand a second time via getAliasingOpOperand. Also, code slightly more readable because we do not have to deal with Optional<> return value. Differential Revision: https://reviews.llvm.org/D110918
This is to avoid code duplication. Differential Revision: https://reviews.llvm.org/D110940
Reuse `getResultBuffer`. Differential Revision: https://reviews.llvm.org/D110941
A recent patch to fix warnings from a Windows build regarding inconsistent "struct" vs "class" usage missed a few code sites and now the "latest-clang" build bot is also failing. This patch should resolve those failing builds.
…moryWrite Move functionality into a separate function `isInplaceMemoryWrite`. Differential Revision: https://reviews.llvm.org/D111040
Do the following optimization for immediate materialisation: 1. For values in range 0xffffffff 7fffffff ~ 0xffffffff 00000000, first generate the lower 32-bit with Val|0x80000000 (which is expected be an int32), then emit (BCLRI r, 31). 2. For values in range 0x80000000 ~ 0xffffffff, first generate the lower 32-bit with Val&~0x80000000 (which is expected to be an int32), then emit (BSETI r, 31). Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D111532
Remove the offending "operator=()" member functions. This should silence the MSVC warnings that persist in uint128.h.
Fuchsia Clang code coverage pipeline started to use binary ids that are embedded in profiles. This patch removes emitting symbolizer markup, which is not necessary in the coverage pipeline anymore. Differential Revision: https://reviews.llvm.org/D111674
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )