[pull] main from llvm:main #20
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}
Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D105416
Some const methods of Expected<T> invoke assertIsChecked(), so we should mark it as const too. Differential Revision: https://reviews.llvm.org/D105292
This adds a new llvm::thread class with the same interface as std::thread except there is an extra constructor that allows us to set the new thread's stack size. On Darwin even the default size is boosted to 8MB to match the main thread. It also switches all users of the older C-style `llvm_execute_on_thread` API family over to `llvm::thread` followed by either a `detach` or `join` call and removes the old API.
…k size." It's causing build failures because DefaultStackSize isn't defined everywhere it should be and I need time to investigate.
- In [D98783](https://reviews.llvm.org/D98783), an extra GlobalDCE pass is inserted before the internalization pass to ensure a global variable without users could be internalized even if there are dead users. Instead of inserting a dedicated optimization pass, the dead user checking, i.e. 'use_empty()', should be preceeded with constant dead user removal to ensure an accurate result. Differential Revision: https://reviews.llvm.org/D105590
This patch adds full qualification to the types and function calls used inside of (Static)InterfaceMethod in OpInterfaces. Without this patch using many of these interfaces in a downstream project yields compiler errors as the types and default implementations are mostly copied verbatim. Without then putting using namespace mlir; in the header file of the implementations of those interfaces, compilation is impossible. Using fully qualified lookup fixes this issue. Differential Revision: https://reviews.llvm.org/D105619
- ``externally_initialized`` variables would be initialized or modified elsewhere. Particularly, CUDA or HIP may have host code to initialize or modify ``externally_initialized`` device variables, which may not be explicitly referenced on the device side but may still be used through the host side interfaces. Not preserving them triggers the elimination of them in the GlobalDCE and breaks the user code. Reviewed By: yaxunl Differential Revision: https://reviews.llvm.org/D105135
… [-]zext/trunc(ctpop(bitcast <n x i1> to in)) to im. Some of the SPEC tests end up with reduction+(sext/zext(<n x i1>) to <n x im>) pattern, which can be transformed to [-]zext/trunc(ctpop(bitcast <n x i1> to in)) to im. Also, reduction+(<n x i1>) can be transformed to ctpop(bitcast <n x i1> to in) & 1 != 0. Differential Revision: https://reviews.llvm.org/D105587
…ack size. This adds a new llvm::thread class with the same interface as std::thread except there is an extra constructor that allows us to set the new thread's stack size. On Darwin even the default size is boosted to 8MB to match the main thread. It also switches all users of the older C-style `llvm_execute_on_thread` API family over to `llvm::thread` followed by either a `detach` or `join` call and removes the old API. Moved definition of DefaultStackSize into the .cpp file to hopefully fix the build on some (GCC-6?) machines.
The unit tests test some implementation details. As @Quuxplusone pointed out in D96664 this should only be tested when the tests use libc++. This addresses the issue for code already in main. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D105568
The format library uses `std::monostate`, but not a `std::variant`. Moving `std::monostate` to its own header allows the format library to reduce the amount of included code. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D105582
…passes This is a cleanup patch -- we're now able to support all flavours of variable location in instruction referencing mode. This patch updates various tests for debug instructions to be broader: numerous code paths try to ignore debug isntructions, and they now have to ignore the additional DBG_PHI and DBG_INSTR_REFs that we can generate. A small amount of rework happens for LiveDebugVariables: as we don't need to track live intervals through regalloc any more, we can get away with unlinking debug instructions before regalloc, then re-inserting them after. Note that this isn't (yet) true of DBG_VALUE_LISTs, they still have to go through live interval tracking. In SelectionDAG, add a helper lambda that emits half-formed DBG_INSTR_REFs for arguments in instr-ref mode, DBG_VALUE otherwise. This is one of the final locations where DBG_VALUEs are emitted for vreg arguments. X86InstrInfo now un-sets the debug instr number on SUB instructions that get mutated into CMP instructions. As the instruction no longer computes a subtraction, we can't use it for variable locations. Differential Revision: https://reviews.llvm.org/D88898
…ort policy In https://lists.llvm.org/pipermail/llvm-dev/2021-March/148881.html, we discussed updating the compiler support policy for libc++ to match more closely what we do actually support. This commit enshrines that policy decision in libc++'s documentation. Differential Revision: https://reviews.llvm.org/D105563
As pointed out in post-commit review on rG8e22539067d9, it's necessary to call getScalarType() to support GEPs with a vector base. Dropping that call was an oversight on my side.
…anymore This is the first of a few commits that update the CI to match the recently officialized compiler support policy. I'm staging those changes to try and keep the CI green at all times, accounting how builders refresh their Docker image.
The pass does not change loops, it just adds calls. Differential Revision: https://reviews.llvm.org/D105583
For the getters, it is bad practice to keep the reference around for too long, as explained in the new comment Reviewed By: gussmith23 Differential Revision: https://reviews.llvm.org/D105599
Notably, a global variable with the metadata should generally not be referenced by a function function. E.g. -fstack-size-section usage is fine, but -fsanitize-coverage= used to have a linker GC problem (fixed by D97430). Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D104933
…ersions Both the conversion cost and the xmm->gpr transfer cost tend to be a lot higher on early SSE targets
There are two issues with the current implementation of computeBECount: 1. It doesn't account for the possibility that adding "Stride - 1" to Delta might overflow. For almost all loops, it doesn't, but it's not actually proven anywhere. 2. It doesn't account for the possibility that Stride is zero. If Delta is zero, the backedge is never taken; the value of Stride isn't relevant. To handle this, we have to make sure that the expression returned by computeBECount evaluates to zero. To deal with this, add two new checks: 1. Use a variety of tricks to try to prove that the addition doesn't overflow. If the proof is impossible, use an alternate sequence which never overflows. 2. Use umax(Stride, 1) to handle the possibility that Stride is zero. Differential Revision: https://reviews.llvm.org/D105216
…an functions This contains all the definitions required by hwasan for the fuchsia implementation and can be landed independently from the remaining parts of D91466. Differential Revision: https://reviews.llvm.org/D103936
This was using the convention from the calling function.
SelectionDAG's equivalents in ISD::InputArg/OutputArg track the original argument index. Mips relies on this, and its currently reinventing its own parallel CallLowering infrastructure which tracks these indexes on the side. Add this to help move towards deleting the custom mips handling.
There was an alias between 'simplifycfg' and 'simplify-cfg' in the PassRegistry. That was the original reason for this patch, which effectively removes the alias. This patch also replaces all occurrances of 'simplify-cfg' by 'simplifycfg'. Reason for choosing that form for the name is that it matches the DEBUG_TYPE for the pass, and the legacy PM name and also how it is spelled out in other passes such as 'loop-simplifycfg', and in other options such as 'simplifycfg-merge-cond-stores'. I for some reason the name should be changed to 'simplify-cfg' in the future, then I think such a renaming should be more widely done and not only impacting the PassRegistry. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D105627
It is confusing to have two ways of specifying the same pass
('simple-loop-unswitch' and 'unswitch'). This patch replaces
'unswitch' by 'simple-loop-unswitch' to get a unique identifier.
Using 'simple-loop-unswitch' instead of 'unswitch' also has the
advantage of matching how the pass is named in DEBUG_TYPE etc. So
this makes it a bit more consistent how we refer to the pass in
options such as -passes, -print-after and -debug-only.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D105628
After this change DSE can eliminate malloc + memset and emit calloc. It's https://reviews.llvm.org/D101440 follow-up. Differential Revision: https://reviews.llvm.org/D103009
…eaders FreeBSD's condvar.h (included by user.h in Threading.inc) uses a "struct thread" that conflicts with llvm::thread if both are visible when it's included. So this moves our #include after the FreeBSD code.
This patch changes the DynamicReloc class to store an enum instead
of the overloaded useSymVA member to make it easier to understand
and fix incorrect addends being written in some corner cases. The
change is motivated by a follow-up review that checks the value of
implicit Elf_Rel addends written to the output file.
This patch fixes an incorrect output when using `-z rela` for i386 files
with R_386_GOT32 relocations (not that this really matters since it's an
unsupported configuration).
Storing the relocation expression kind also addresses an incorrect addend
FIXME in ppc64-abs64-dyn.s introduced in D63383.
DynamicReloc now also has a special case for the MIPS TLS relocations
(DynamicReloc::AgainstSymbolWithTargetVA) since the
R_MIPS_TLS_TPREL{32/64} the symbol VA to the GOT for preemptible
symbols. I'm not sure if the symbol value actually should be written
for R_MIPS_TLS_TPREL32, but this patch does not attempt to change
that behaviour.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D100490
There used to be many cases where addends for Elf_Rel were not emitted in the final object file (mostly when building for MIPS64 since the input .o files use RELA but the output uses REL). These cases have been fixed since, but this patch adds a check to ensure that the written values are correct. It is based on a previous patch that I added to the CHERI fork of LLD since we were using MIPS64 as a baseline. The work has now almost entirely shifted to RISC-V and Arm Morello (which use Elf_Rela), but I thought it would be useful to upstream our local changes anyway. This patch adds a (hidden) command line flag --check-dynamic-relocations that can be used to enable these checks. It is also on by default in assertions builds for targets that handle all dynamic relocations kinds that LLD can emit in Target::getImplicitAddend(). Currently this is enabled for ARM, MIPS, and I386. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101450
This allows checking dynamic relocation addends for -z rel and --apply-dynamic-relocs output. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101451
I found this missing case with the new --check-dynamic-relocation flag while running the lld tests with --apply-dynamic-relocs enabled by default. This also fixes a broken CHECK in lld/test/ELF/x86-64-gotpc-relax.s: The test wasn't using CHECK-NEXT, so it was passing despite the output actually containing relocations. I am not sure when this changed, but I think this behaviour is correct. Found with D101450 + enabling --apply-dynamic-relocs by default. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101452
I found this missing case with the new --check-dynamic-relocation flag while running the lld tests with --apply-dynamic-relocs enabled by default. This is the same as D101452 just for RISC-V Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101454
This allows checking dynamic relocation addends for -z rel and --apply-dynamic-relocs output. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101455
Since D100490 this case is diagnosed for -z rel. This commit implements R_AARCH64_TLSDESC cases for AArch64::getImplicitAddend() and AArch64::relocate(). However, there are probably further relocation types that need to be handled for full support of -z rel. Fixes https://bugs.llvm.org/show_bug.cgi?id=47009 Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D100544
A change in the API happened as per http://reviews.llvm.org/D89463 (latest related commit b9e2b59) but the RST documentation was not updated to match this at that time.
…lity * Drop any mention of `volatile`. Please refer to https://reviews.llvm.org/D105338 * Drop address space check - it really doesn't affect the behavior, the store will still be dropped: https://godbolt.org/z/dP8fevxG4
…- use trap Please refer to https://reviews.llvm.org/D105338, such store will not trap, it will be removed.
This is a follow up to D105628 (commit 1db2551). I had missed to replace 'unswitch' by 'simple-loop-unswitch' in one place.
This is needed because the functions `isl_union_{set,map}_get_{set,map}_list` have been exposed to the C++ interface
…null isn't erased
…y on volatile store to null trapping This fallback path is used at least on PPC. If this doesn't work on some compilers that take this path, then this will have to be changed to either abort, or partitioned to do different things based on the compiler. Please refer to https://reviews.llvm.org/D105338.
This patch removes the IsPairwiseForm flag from the Reduction Cost TTI hooks, along with some accompanying code for pattern matching reductions from trees starting at extract elements. IsPairWise is now assumed to be false, which was the predominant way that the value was used from both the Loop and SLP vectorizers. Since the adjustments such as D93860, the SLP vectorizer has not relied upon this distinction between paiwise and non-pairwise reductions. This also removes some code that was detecting reductions trees starting from extract elements inside the costmodel. This case was double-counting costs though, adding the individual costs on the individual instruction _and_ the total cost of the reduction. Removing it changes the costs in llvm/test/Analysis/CostModel/X86/reduction.ll to not double count. The cost of reduction intrinsics is still tested through the various tests in llvm/test/Analysis/CostModel/X86/reduce-xyz.ll. Differential Revision: https://reviews.llvm.org/D105484
…ation Added check for switch-terminated blocks in loops. Now if a block is terminated with a switch, we try to find out which of the cases is taken on 1st iteration and mark corresponding edge from the block to the case successor as live. Patch by Dmitry Makogon! Differential Revision: https://reviews.llvm.org/D105688 Reviewed By: nikic, mkazantsev
…ults to let us add AssertSext/AssertZext Its proving tricky to move this to the generic legalizer code, so manually insert the v2i32 subvector into v4i32, insert the AssertSext/AssertZext node, then extract the subvector again. This avoids masks in the truncation/pack code, which means we avoid a PSHUFB in the fp_to_sint/uint code for sub-128 bit types (specific targets can still combine the packs to a pshufb if they have fast variable per-lane shuffles). This was noticed when I was trying to improve fp_to_sint/uint costs with D103695 (and some targets had very high fp_to_sint costs due to the PSHUFB), so we can then update the fp_to_uint codegen from D89697.
This reverts commit 4e413e1, which landed almost 10 months ago under premise that the original behavior didn't match reality and was breaking users, even though it was correct as per the LangRef. But the LangRef change still hasn't appeared, which might suggest that the affected parties aren't really worried about this problem. Please refer to discussion in: * https://reviews.llvm.org/D87399 (`Revert "[InstCombine] erase instructions leading up to unreachable"`) * https://reviews.llvm.org/D53184 (`[LangRef] Clarify semantics of volatile operations.`) * https://reviews.llvm.org/D87149 (`[InstCombine] erase instructions leading up to unreachable`) clang has `-Wnull-dereference` which will diagnose the obvious cases of null dereference, it was adjusted in f4877c7, but it will only catch the cases where the pointer is a null literal, it will not catch the cases where an arbitrary store is expected to trap. Differential Revision: https://reviews.llvm.org/D105338
This reverts commit 5b35018 (and also "[NFC][ScalarEvolution] Cleanup howManyLessThans.", 009436e, to make it apply). See https://reviews.llvm.org/D105216 for discussion on various miscompilations caused by that commit.
This matches what rc.exe tolerates in this type.
This fixes cases like this:
1 24
BEGIN
"<?xml version=""1.0""?>\n"
"<assembly>\n"
"</assembly>\n"
END
Differential Revision: https://reviews.llvm.org/D105621
…ine.cpp test Store to null is deleted, so the test no longer did what it was expecting to do. Conceal that by creating null pointer in a more elaborate way, thus retaining original test coverage.
…raps and is not erase Instead, mostly just trap directly.
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 : )