[pull] main from llvm:main #5540
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}
The tests were a bit of a mess -- the testing coverage wasn't bad but it was extremely difficult to see what was being tested and where. I split up the tests to make them easier to audit for completeness and did such an audit, adding a few missing tests (e.g. the conditional noexcept-ness of std::cbegin and std::cend). I also audited the synopsis and adjusted it where it needed to be adjusted. This patch is in preparation of fixing #67471.
…sts (#67559) We don't neeed to handle both spellings anymore since we don't support Clang 15 anymore.
#67630) The vectorization of the FindLastIV reduction does not depend on the nocapture and readonly attributes.
Avoid an unnecessary use of ConstantExpr::getZExt() when APInt::zext() is sufficient.
In preparation for removing these constant expressions.
This makes some tests robust against minor codegen differences that will be caused by PR #67038.
(This fails if the input is not writable)
We don't require a Constant here, so let IRBuilder fold this.
Let the IRBuilder constant fold instead.
From two aspects: - For function templates, emit additional template argument placeholders in the context where it can't be a call in order to specify an instantiation explicitly. - Consider expressions with base type specifier such as 'Derived().Base::foo^' a function call. Reviewed By: nridge Differential Revision: https://reviews.llvm.org/D156605
Use IRBuilder instead, which will either insert an instruction or constant fold.
Work on APInt instead.
Instead work on APInt.
This patch updates `transform.loop.peel` so that this Op returns two rather than one handle: * one for the peeled loop, and * one for the remainder loop. Also, following this change this Op will fail if peeling fails. This is consistent with other similar Ops that also fail if no transformation takes place. Relands #67482 with an extra fix for transform_loop_ext.py
…llvm.mlir test Fix mistyped syntax in omptarget-region-parallel-llvm.mlir test added by b05d436
This addresses missing cmake files needed to build some sub-projects like libstdcxx. Co-authored-by: René Rebe <rene@exactcode.de>
Define operations that wrap the gfx940's new operations for converting between f32 and registers containing packed sets of four 8-bit floats. Define rocdl operations for the intrinsics and an AMDGPU dialect wrapper around them (to account for the fact that MLIR distinguishes the two float formats at the type level but that the LLVM IR does not). Define an ArithToAMDGPU pass, meant to run before conversion to LLVM, that replaces relevant calls to arith.extf and arith.truncf with the packed operations in the AMDGPU dialect. Note that the conversion currently only handles scalars and vectors of rank <= 1, as we do not have a usecase for multi-dimensional vector support right now. Reviewed By: jsjodin Differential Revision: https://reviews.llvm.org/D152457
Use the constant folding API instead. In preparation for dropping zext constant expressions.
Summary: These wrapper headers need to work around things in the standard headers. The existing workarounds didn't correctly handle the macros for `iscascii` and `toascii`. Additionally, `memrchr` can't be used because it has a different declaration for C++ mode. Fix this so it can be compiled.
Add helpers getLosslessUnsignedTrunc/getLosslessSignedTrunc for this common pattern.
…7650) There is a crash before hitting the TODO when the length parameter kind depends on a KIND parameter. I do not want to fix it since I cannot test it because of the TODO, so I just moved to TODO up and added a comment.
Use the constant folding API instead, which should always succeed in this case.
Check the result of constant folding here, as I'm not confident that no constant expressions can make it in here.
Splitting up patches for #20571. I found these comments generally useful to add and not predicated on those changes. Hopefully they help future travelers.
… init anything (#67638) Close #56794 And see #67582 for a detailed backgrond for the issue. As required by the Itanium ABI, the module units have to generate the initialization function. However, the importers are allowed to elide the call to the initialization function if they are sure the initialization function doesn't do anything. This patch implemented this semantics.
Assumed shape array are using descriptor and must be handled differently than known shape arrays. This patch adds support to generate the `init` and `combiner` region for the reduction recipe operation with assumed shape array by using the descriptor and the HLFIR lowering path. `createTempFromMold` function is moved from `flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp` to `flang/include/flang/Optimizer/Builder/HLFIRTools.h` to be reused to create the private copy.
This patch adds the OutlineableOpenMPOpInterface to omp.target. This prevents other operations inside the target region such as WSLoop from hoisting new allocas outside the region.
This patch tentatively fixes the various test failures introduced following 0ea3d88: https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/6316/ From my understanding, the main issue here is that we can't find some headers when evaluating C++ expressions since those headers have been promoted to be system modules, and to be shipped as part of the toolchain. Prior to 0ea3d88, the `BuiltinHeadersInSystemModules` flag for in the clang `LangOpts` struct was always set, however, after it landed, the flag becomes opt-in, depending on toolchain that is used with the compiler instance. This gets set in `clang::createInvocation` down to `Darwin::addClangTargetOptions`, as this is used mostly on Apple platforms. However, since `ClangExpressionParser` makes a dummy `CompilerInstance`, and sets the various language options arbitrarily, instead of using the `clang::createInvocation`, the flag remains unset, which causes the various error messages: ``` AssertionError: 'error: module.modulemap:96:11: header 'stdarg.h' not found 96 | header "stdarg.h" // note: supplied by the compiler | ^ ``` Given that this flag was opt-out previously, this patch brings back that behavior by setting it in lldb's `ClangExpressionParser` constructor, until we actually decide to pull the language options from the compiler driver. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
At line 191, `addSymbol` takes the name by reference but does not make an internal copy to the string, meaning the local `optional<std::string>` would get freed and leave Orc with a dangling pointer. Fix this by just using an `optional<StringRef>` instead.
…67871) Variables that point to physical storage buffer require aliasing decorations. This is specified by the `SPV_KHR_physical_storage_buffer` extension. Also add an example of a variable with a decoration attribute.
The goal of the class is to be an (almost) drop in replacement for SmallVector and std::vector when those are presized and filled later, as it happens in SourceManager and ASTReader. By doing so, sparsely accessed PagedVector can profit from reduced memory footprint.
This patch replaces any_cast with llvm::any_cast. This in turn allows
us to gracefully switch to std::any in future by forwarding llvm::Any
and llvm::any_cast to:
using Any = std::any;
template <class T> T *any_cast(Any *Value) {
return std::any_cast<T>(Value);
}
respectively.
Without this patch, it's ambiguous whether any_cast refers to
std::any_cast or llvm::any_cast.
As an added bonus, this patch makes it easier to mechanically replace
llvm::any_cast with std::any_cast without affecting other occurrences of
any_cast (e.g. in libcxx).
After patch #67288 landed, unfoldMemoryOperand would not return NewMIs whose size ==3. So the removed line is useless.
It always returns false in the unwrapped line parser!
Most of the print options are hidden, make hidden them all.
To do this: 1. Protect BC.Ctx with mutex 2. Don't call exit from thread, please check the reason comment near PassFailed variable definition. The other option would be call _Exit instead of exit, but I think we shall call destructors properly.
The AArch64StorePairSuppress pass prevents the creation of STP under some heuristics. Unfortunately it often prevents the creation of STP in cases where it is obviously beneficial, and it doesn't match my understanding of scheduling/cpu pipelining to prevent the creation of STP. From some benchmarking, even on an in-order cpu where the scheduling is most important I don't see it giving better results. In general the lower instruction count for STP would be expected to give a slightly better cycle count. As the pass specifically mentions the cyclone cpu, this patch adds a target feature for FeatureStorePairSuppress, enabled for all the non-Arm cpus. This has the effect of disabling it for all Arm cpus. Differential Revision: https://reviews.llvm.org/D134646
* Remove if its sole use is to support an unnecessary ptr-to-ptr bitcast (remove the bitcast as well) * Replace with use of other APIs. NFC opaque pointer cleanup effort.
* Remove if its sole use is to support an unnecessary ptr-to-ptr bitcast (remove the bitcast as well) * Replace with use of other APIs. NFC opaque pointer cleanup effort.
…ng modes The newly added tests check which rounding mode is used by default, and that it is printed when aliases are disabled but not otherwise. These tests will be used in #67555.
… instrs (#65228) Fixes #65227 LLVMGetOrdering previously did not support Fence instructions, and calling it on a fence would lead to a bad cast as it assumed a load/store, or an AtomicRMWInst. This would either read a garbage memory order, or assertion LLVMIsAtomicSingleThread did not support either Fence instructions, loads, or stores, and would similarly lead to a bad cast. It happened to work out since the relevant types all have their synch scope ID at the same offset, but it still should be fixed These cases are now fixed for the C API, and tests for these instructions are added. The echo test utility now also supports cloning Fence instructions, which it did not previously ----- From what I can tell, there's no unified API to pull `getOrdering`/`getSyncScopeID` from, and instead requires casting to individual types: if there is a better way of handling this I can switch to that
…ntime LLVM integration See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details. Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md). This patch aims to: - integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime - decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime - add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target. - provide documentation on how to build and use the new FlangRT runtime Reviewed By: DanielCChen Differential Revision: https://reviews.llvm.org/D154869
This adds `IntegralAP` backing the two new primtypes `IntAP` (unsigned arbitrary-precision int) and `IntAPS` (same but signed). We use this for `int128` support (which isn't available on all host systems we support AFAIK) and I think we can also use this for `_BitInt` later.
These are not available in all build configurations. Originally introuduced in: #66430
This seems to be an issue common to both GCC and LLVM. There are various RISC-V FCVT instructions where the frm field makes no difference to the output as the result is always exact (e.g. fcvt.d.s, fcvt.s.h, fcvt.d.h). As with GCC, we always generate a form of these fcvt instructions where frm=0b000. However, the ISA manual _doesn't_ state that frm values are invalid, and we should ensure we can accept them. This patch does so by adding the frm field to fcvt.d.s and adding an InstAlias so that if no frm is specified, it defaults to rne (0b000). This patch just corrects fcvt.d.s in order to allow the approach to be reviewed, before applying it to the other affected instructions. I haven't added tests to llvm/test/MC/Disassembler/RISCV, because it doesn't seem necessary to test there in addition to our usual round-trip tests in llvm/test/MC/RISCV. But feedback is welcome. Recently added tests ensure that the default `rne` rounding mode is printed as desired.
Xcode `lipo` seems to support a non-documented `-fat64` option that creates Universal Mach-O archives using 64 bit versions of the `fat_arch` header, which allows offsets larger than 32 bits to be specified. Modify `llvm-lipo` to support the same flag, and use the value of the flag to use either 32 bits or 64 bits Mach-O headers. The Mach-O universal writer allows specifying a new option to write these 64 bits headers. The default is still using 32 bits. `dsymutil` implemented support for a similar flag in https://reviews.llvm.org/D146879.
/llvm-project/llvm/lib/Object/MachOUniversalWriter.cpp:351:3: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default] default: ^ 1 error generated.
Followup to #67628 that relaxes the symbol regex a bit to cover more lldb_private symbols.
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Object\MachOUniversalWriter.cpp(352) : error C2220: the following warning is treated as an error C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Object\MachOUniversalWriter.cpp(352) : warning C4715: 'llvm::object::writeUniversalBinaryToStream': not all control paths return a value
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 : )