[AutoBump] Merge with f035d9f0 (Oct 15) (13) #450
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
This patch implements the `ConvertToLLVMPatternInterface` for the OpenMP dialect, allowing `convert-to-llvm` to act on the OpenMP dialect.
The API was already using top()/bottom() but internally we were still using From/To. This patch fixes this. Top/Bottom seems a better choice because implies program order, whereas From/To does not.
Builds on llvm#73789, enabling store clustering by default using the same heuristic.
When encountering an instruction like `if (p0) r0 = add(r0,##bar@GOT)`, lld would fail with: ``` ld.lld: error: unrecognized instruction for 16_X type: 0x7400C000 ``` This issue was encountered while building libreadline with clang 19.1.0. Fixes: llvm#111876
a non-functional change Update test script with update_mc_test_check script and sort the testline to be alphabetic order. This helps to maintain the test file in a clean state
We have two (EDIT: 4) files in which we are using `I`. This PR replaces them with alternatives like `i` and `IDX` etc.
This patch enables support for cloning in indirect callsites. This is done by synthesizing callsite records for each virtual call target from the profile metadata. In the thin link all the synthesized records for a particular indirect callsite initially share the same context node, but support is added to partition the callsites and outgoing edges based on the callee function, creating a separate node for each target. In the LTO backend, when cloning is needed we first perform indirect call promotion, then change the target of the new direct call to the desired clone. Note this is ThinLTO-specific, since for regular LTO indirect call promotion should have already occurred.
…ributes (llvm#110334) We already have support for declaration attributes; this is just a matter of extending the plugin infrastructure to cover one more case.
The patch added orc-b-patterns.ll landed while store clustering was still in review.
…11095) ReplaceWithVeclib.cpp would construct overload name using all the arguments in the intrinsic, but overloads should only be constructed from arguments for which isVectorIntrinsicWithOverloadTypeAtArg returns true, including the return type first (index -1). Additionally, - skip when `Intrinsic::not_intrinsic`, otherwise `isVectorIntrinsicWithOverloadTypeAtArg` asserts for some IntrinsicCalls. Unblocks translation for pow and atan2 intrinsics. Fixes llvm#111093
…111917) `parent_id` and `stack_id` represent location where the thread was created, so it's reasonable to keep them togeter. For now, only Asan and MemProf use `stack_id`, but it will be halpfull to print thread origin from other sanitizers as well. For llvm#111948
Needed for llvm#110894 The strtointeger code was updated to support some bigint types in llvm#85201 but not all. This patch finishes the cleanup so that it can work for a wider range of types.
…ing isel pattern. I just happened to notice the untested isel pattern.
There are hard to debug leaks which look like false. In general, repeating leak checking should not affect set of leaks significantly, especial `at_exit` leak checking. But if we see significant discrepancy, it may give us a clue for investigation.
`llvm::Type::getPointerTo()` is to be deprecated & removed soon.
…_with patterns (llvm#110448) Add support for the following two patterns: ``` haystack.compare(haystack.length() - needle.length(), needle.length(), needle) == 0; haystack.rfind(needle) == (haystack.size() - needle.size()); ```
Only with high verbosity and leak reports, or thread logging requested.
…mments without breaking internal structure (think Doxygen). (llvm#96804) * Convert `ReflowComments` from boolean into a new `enum` which can take on the value `RCS_Never`, `RCS_IndentOnly`, or `RCS_Always`. The first one is equivalent to the old `false`, the third one is `true`, and the middle one means that multiline comments should only have their indentation corrected, which is what Doxygen users will want. * Preserve backward compatibility while parsing `ReflowComments`.
Attempt to fit sporadic precommit test failures in hip-partial-link.hip The driver really shouldn't be using llvm-mc in the first place though, filed llvm#112031 to fix this.
This typo causes alive2 to crash.
…3421) The `PGOInstrumentationGen` pass should preserve all analysis results when nothing was actually instrumented. Currently, only modules that contain at least a single function definition are instrumented. When a module contains only function declarations and, optionally, global variable definitions (a module for the regular-LTO phase for thin-LTO when LTOUnit splitting is enabled, for example), such module is not instrumented (yet?) and there is no reason to invalidate any analysis results. NFC.
…ers (llvm#112177) When parsing its function parameters, we don't change the CurContext to the lambda's function declaration. However, CheckIfAnyEnclosingLambdasMustCaptureAnyPotentialCaptures() has not yet adapted to such behavior when nested lambdas come into play. Consider the following case, struct Foo {}; template <int, Foo f> struct Arr {}; constexpr void foo() { constexpr Foo F; [&]<int I>() { [&](Arr<I, F>) {}; }.template operator()<42>(); } As per [basic.def.odr]p5.2, the use of F constitutes an ODR-use. And per [basic.def.odr]p10, F should be ODR-usable in that interleaving scope. We failed to accept the case because the call to tryCaptureVariable() in getStackIndexOfNearestEnclosingCaptureCapableLambda() suggested that F is needlessly captureable. That was due to a missed handling for AfterParameterList in FunctionScopeIndexToStopAt, where it still presumed DC and LSI matched. Fixes llvm#47400 Fixes llvm#90896
(reland with fixed sed command for macos) Handle the `!callees` metadata to further reduce the amount of indirect call cases that end up conservatively assuming that any indirectly callable function is a potential target.
`APFloat::APFloat(const fltSemantics &Semantics, integerPart I)` interprets 'I' as a unsigned integer. Fix the bug found in llvm#112113 (comment).
Use explicit target and stop restricting hosts it can run on.
…12238) Comparing their PrimTypes isn't enough in this case. We can have a floating cast here as well.
The [last attempt](llvm#89036) to fix llvm#41441 has been reverted immediately. Here I'm trying the simplest idea I've been able to come with: skip handling dependent case in `BuildCXXNew`. The original test (borrowed form llvm#89036) passes. Also I've created and added to the tests a minimal repro of the code llvm#89036 fails on. This (obviously) also passes.
…112316) Use const pointers for various `Init` objects. This is a part of effort to have better const correctness in TableGen backends: https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
…terializations (llvm#112128) This commit adds an optional `originalType` parameter to target materialization functions. Without this parameter, target materializations are underspecified. Note: `originalType` is only needed for target materializations. Source/argument materializations do not have it. Consider the following example: Let's assume that a conversion pattern "P1" replaced an SSA value "v1" (type "t1") with "v2" (type "t2"). Then a different conversion pattern "P2" matches an op that has "v1" as an operand. Let's furthermore assume that "P2" determines that the legalized type of "t1" is "t3", which may be different from "t2". In this example, the target materialization callback will be invoked with: outputType = "t3", inputs = "v2", originalType = "t1". Note that the original type "t1" cannot be recovered from just "t3" and "v2"; that's why the `originalType` parameter is added. This change is in preparation of merging the 1:1 and 1:N dialect conversion drivers. As part of that change, argument materializations will be removed (as they are no longer needed; they were just a workaround because of missing 1:N support in the dialect conversion). The new `originalType` parameter is needed when lowering MemRef to LLVM. During that lowering, MemRef function block arguments are replaced with the elements that make up a MemRef descriptor. The type converter is set up in such a way that the legalized type of a MemRef type is an `!llvm.struct` that represents the MemRef descriptor. When the bare pointer calling convention is enabled, the function block arguments consist of just an LLVM pointer. In such a case, a target materialization will be invoked to construct a MemRef descriptor (output type = `!llvm.struct<...>`) from just the bare pointer (inputs = `!llvm.ptr`). The original MemRef type is required to construct the MemRef descriptor, as static sizes/strides/offset cannot be inferred from just the bare pointer.
Add an additional adaptor constructor that copies everything except for the values. The values are provided with by a second parameter. This commit is in preparation of merging the 1:1 and 1:N dialect conversions. As part of that, a new `matchAndRewrite` function is added. For details, see this RFC: https://discourse.llvm.org/t/rfc-merging-1-1-and-1-n-dialect-conversions/82513 ```c++ template <typename SourceOp> class OpConversionPattern : public ConversionPattern { public: using OneToNOpAdaptor = typename SourceOp::template GenericAdaptor<ArrayRef<ArrayRef<Value>>>; virtual LogicalResult matchAndRewrite(SourceOp op, OneToNOpAdaptor adaptor, ConversionPatternRewriter &rewriter) const { SmallVector<Value> oneToOneOperands = getOneToOneAdaptorOperands(adaptor.getOperands()); // This OpAdaptor constructor is added by this commit. return matchAndRewrite(op, OpAdaptor(oneToOneOperands, adaptor), rewriter); } }; ```
…vm#112172) This adds computeKnownBits support for vector->vector G_UNMERGE_VALUES, grabbing the known bits with an adjusted DemandedElts mask.
This makes sure that APInt::getAllOnes() keeps working after the APInt constructor assertions are enabled. I'm relaxing the requirement for the signed case to either an all zeros or all ones integer. This is basically saying that we can interpret the zero-width integer as either positive or negative.
This fixes a problem introduced in llvm#80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string should have `+simd128`, not `-simd128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead.
9ad72df added split of _BitInt constants when required. Before folding back, check that the constant exists.
Implementation of `computeCost()` function for `VPReductionRecipe`. Note that `in-loop` and `any-of` reductions are not supported by VPlan-based cost model currently.
When investigating PR llvm#101634, it turned out that `UBSan-Standalone-sparc :: TestCases/Misc/Linux/diag-stacktrace.cpp` isn't Linux-specific at all. In fact, none of the `ubsan/TestCases/Misc/Linux` tests are. Therefore this patch moves them to `Misc/Posix` instead. Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`, `x86_64-pc-linux-gnu`, and `amd64-pc-solaris2.11`.
When testing on Linux/sparc64 with a `runtimes` build, the `UBSan-Standalone-sparc :: TestCases/Misc/Linux/sigaction.cpp` test `FAIL`s: ``` runtimes/runtimes-bins/compiler-rt/test/ubsan/Standalone-sparc/TestCases/Misc/Linux/Output/sigaction.cpp.tmp: error while loading shared libraries: libclang_rt.ubsan_standalone.so: wrong ELF class: ELFCLASS64 ``` It turns out SPARC needs the same `LD_LIBRARY_PATH` handling as x86. This is what this patch does, at the same time noticing that the current duplication between `lit.common.cfg.py` and `asan/Unit/lit.site.cfg.py.in` isn't necessary. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
This PR would fix llvm#16855 . The correct lookup to use for class names is Tag name lookup, because it does not take namespaces into account. The lookup before does and because of this some valid programs are not accepted. An example scenario of a valid program being declined is when you have a struct (let's call it `y`) inheriting from another struct with a name `x` but the struct `y` is in a namespace that is also called `x`: ``` struct x {}; namespace { namespace x { struct y : x {}; } } ``` This shall be accepted because: ``` C++ [class.derived]p2 (wrt lookup in a base-specifier): The lookup for // the component name of the type-name or simple-template-id is type-only. ```
Some typos are also fixed. Address llvm#112067 (review).
Write dedicated tests for foldSelectValueEquivalence, demonstrating that it does not perform many GVN-like replacements when: - the comparison is a vector-type - the comparison is a floating-point type as a prelude to fixing these deficiencies.
LDV could reorder reinserted fragment and non-fragment debug values for the same variable (compared to the input order), potentially resulting in stale values being presented. For example, before: DBG_VALUE 1001, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 0, 16) DBG_VALUE 1002, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 16, 16) DBG_VALUE %0, $noreg, !13, !DIExpression() After (without this patch): DBG_VALUE %stack.0, 0, !13, !DIExpression() DBG_VALUE 1002, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 16, 16) DBG_VALUE 1001, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 0, 16) It would also reorder DBG_VALUEs for different variables. Although that does not matter for the debug information output, it resulted in some noise in before/after pass diffs. This should hopefully align so that instruction referencing and DBG_VALUE emit debug instructions in the same order (see the sdag-salvage-add.ll change).
…to scalar Constant{Int,FP}. (llvm#111005)
This fixes a failure path when the use-constant-##-for-###-splat IR
options are enabled.
foldSelectEquivalence currently doesn't support GVN-like replacements on vector types. Put in the checks for potentially lane-crossing operations, and lift the limitation.
…inked with libc++ statically (llvm#98694) This is to fix buildbot failure https://lab.llvm.org/staging/#/builders/195/builds/4255. The test expects 'libstdc++' or 'libc++' SO module in the module list. In case when static linking with libc++ is on by default, none of them may be present. Thus, USE_SYSTEM_STDLIB is added to ensure the presence of any of them. --------- Co-authored-by: Vladimir Vereschaka <[email protected]>
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.
No description provided.