aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/AutoUpgrade.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-06-14Intrinsic::getName: require a Module argumentJeroen Dobbelaere1-8/+14
Ensure that we provide a `Module` when checking if a rename of an intrinsic is necessary. This fixes the issue that was detected by https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32288 (as mentioned by @fhahn), after committing D91250. Note that the `LLVMIntrinsicCopyOverloadedName` is being deprecated in favor of `LLVMIntrinsicCopyOverloadedName2`. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D99173
2021-05-20[IR][AutoUpgrade] Drop alignment from non-pointer parameters and returnsSteven Wu1-5/+5
This is a follow-up of D102201. After some discussion, it is a better idea to upgrade all invalid uses of alignment attributes on function return values and parameters, not just limited to void function return types. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D102726
2021-05-17[AArch64] Lower bitreverse in ISelIrina Dobrescu1-0/+5
Adding lowering support for bitreverse. Previously, lowering bitreverse would expand it into a series of other instructions. This patch makes it so this produces a single rbit instruction instead. Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D102397
2021-05-11[IR][AutoUpgrade] Drop align attribute from void return typesSteven Wu1-0/+6
Since D87304, `align` become an invalid attribute on none pointer types and verifier will reject bitcode that has invalid `align` attribute. The problem is before the change, DeadArgumentElimination can easily turn a pointer return type into a void return type without removing `align` attribute. Teach Autograde to remove invalid `align` attribute from return types to maintain bitcode compatibility. rdar://77022993 Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D102201
2021-05-05Preserve metadata on masked intrinsics in auto-upgradeKrzysztof Parzyszek1-1/+7
When auto-upgrade was replacing a call to a masked intrinsic, it would not copy the metadata from the original call. If an intrinsic had metadata, but did not need any updates, the metadata would stay, but if an update was needed, the would end up being removed. A similar effect could be observed with masked_expandload and masked_compressstore, which at the moment are not handled by auto-upgrade: the metadata remained untouched. Differential Revision: https://reviews.llvm.org/D101201
2021-03-17[AArch64][SVE/NEON] Add support for FROUNDEVEN for both NEON and fixed ↵Bradley Smith1-0/+5
length SVE Previously NEON used a target specific intrinsic for frintn, given that the FROUNDEVEN ISD node now exists, move over to that instead and add codegen support for that node for both NEON and fixed length SVE. Differential Revision: https://reviews.llvm.org/D98487
2021-03-08Move ObjCARCUtil.h back to llvm/AnalysisAkira Hatanaka1-2/+1
Instead of adding the header to llvm/IR, just duplicate the marker string in the auto upgrader.
2021-03-04Move llvm/Analysis/ObjCARCUtil.h to IR to fix layering.David Blaikie1-1/+1
This is included from IR files, and IR doesn't/can't depend on Analysis (because Analysis depends on IR). Also fix the implementation - don't use non-member static in headers, as it leads to ODR violations, inaccurate "unused function" warnings, etc. And fix the header protection macro name (we don't generally include "LIB" in the names, so far as I can tell).
2021-03-04[ObjC][ARC] Use operand bundle 'clang.arc.attachedcall' instead ofAkira Hatanaka1-2/+3
explicitly emitting retainRV or claimRV calls in the IR This reapplies ed4718eccb12bd42214ca4fb17d196d49561c0c7, which was reverted because it was causing a miscompile. The bug that was causing the miscompile has been fixed in 75805dce5ff874676f3559c069fcd6737838f5c0. Original commit message: Background: This fixes a longstanding problem where llvm breaks ARC's autorelease optimization (see the link below) by separating calls from the marker instructions or retainRV/claimRV calls. The backend changes are in https://reviews.llvm.org/D92569. https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue What this patch does to fix the problem: - The front-end adds operand bundle "clang.arc.attachedcall" to calls, which indicates the call is implicitly followed by a marker instruction and an implicit retainRV/claimRV call that consumes the call result. In addition, it emits a call to @llvm.objc.clang.arc.noop.use, which consumes the call result, to prevent the middle-end passes from changing the return type of the called function. This is currently done only when the target is arm64 and the optimization level is higher than -O0. - ARC optimizer temporarily emits retainRV/claimRV calls after the calls with the operand bundle in the IR and removes the inserted calls after processing the function. - ARC contract pass emits retainRV/claimRV calls after the call with the operand bundle. It doesn't remove the operand bundle on the call since the backend needs it to emit the marker instruction. The retainRV and claimRV calls are emitted late in the pipeline to prevent optimization passes from transforming the IR in a way that makes it harder for the ARC middle-end passes to figure out the def-use relationship between the call and the retainRV/claimRV calls (which is the cause of PR31925). - The function inliner removes an autoreleaseRV call in the callee if nothing in the callee prevents it from being paired up with the retainRV/claimRV call in the caller. It then inserts a release call if claimRV is attached to the call since autoreleaseRV+claimRV is equivalent to a release. If it cannot find an autoreleaseRV call, it tries to transfer the operand bundle to a function call in the callee. This is important since the ARC optimizer can remove the autoreleaseRV returning the callee result, which makes it impossible to pair it up with the retainRV/claimRV call in the caller. If that fails, it simply emits a retain call in the IR if retainRV is attached to the call and does nothing if claimRV is attached to it. - SCCP refrains from replacing the return value of a call with a constant value if the call has the operand bundle. This ensures the call always has at least one user (the call to @llvm.objc.clang.arc.noop.use). - This patch also fixes a bug in replaceUsesOfNonProtoConstant where multiple operand bundles of the same kind were being added to a call. Future work: - Use the operand bundle on x86-64. - Fix the auto upgrader to convert call+retainRV/claimRV pairs into calls with the operand bundles. rdar://71443534 Differential Revision: https://reviews.llvm.org/D92808
2021-03-03Revert "[ObjC][ARC] Use operand bundle 'clang.arc.attachedcall' instead of ↵Hans Wennborg1-1/+1
explicitly emitting retainRV or claimRV calls in the IR" This caused miscompiles of Chromium tests for iOS due clobbering of live registers. See discussion on the code review for details. > Background: > > This fixes a longstanding problem where llvm breaks ARC's autorelease > optimization (see the link below) by separating calls from the marker > instructions or retainRV/claimRV calls. The backend changes are in > https://reviews.llvm.org/D92569. > > https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue > > What this patch does to fix the problem: > > - The front-end adds operand bundle "clang.arc.attachedcall" to calls, > which indicates the call is implicitly followed by a marker > instruction and an implicit retainRV/claimRV call that consumes the > call result. In addition, it emits a call to > @llvm.objc.clang.arc.noop.use, which consumes the call result, to > prevent the middle-end passes from changing the return type of the > called function. This is currently done only when the target is arm64 > and the optimization level is higher than -O0. > > - ARC optimizer temporarily emits retainRV/claimRV calls after the calls > with the operand bundle in the IR and removes the inserted calls after > processing the function. > > - ARC contract pass emits retainRV/claimRV calls after the call with the > operand bundle. It doesn't remove the operand bundle on the call since > the backend needs it to emit the marker instruction. The retainRV and > claimRV calls are emitted late in the pipeline to prevent optimization > passes from transforming the IR in a way that makes it harder for the > ARC middle-end passes to figure out the def-use relationship between > the call and the retainRV/claimRV calls (which is the cause of > PR31925). > > - The function inliner removes an autoreleaseRV call in the callee if > nothing in the callee prevents it from being paired up with the > retainRV/claimRV call in the caller. It then inserts a release call if > claimRV is attached to the call since autoreleaseRV+claimRV is > equivalent to a release. If it cannot find an autoreleaseRV call, it > tries to transfer the operand bundle to a function call in the callee. > This is important since the ARC optimizer can remove the autoreleaseRV > returning the callee result, which makes it impossible to pair it up > with the retainRV/claimRV call in the caller. If that fails, it simply > emits a retain call in the IR if retainRV is attached to the call and > does nothing if claimRV is attached to it. > > - SCCP refrains from replacing the return value of a call with a > constant value if the call has the operand bundle. This ensures the > call always has at least one user (the call to > @llvm.objc.clang.arc.noop.use). > > - This patch also fixes a bug in replaceUsesOfNonProtoConstant where > multiple operand bundles of the same kind were being added to a call. > > Future work: > > - Use the operand bundle on x86-64. > > - Fix the auto upgrader to convert call+retainRV/claimRV pairs into > calls with the operand bundles. > > rdar://71443534 > > Differential Revision: https://reviews.llvm.org/D92808 This reverts commit ed4718eccb12bd42214ca4fb17d196d49561c0c7.
2021-02-25Add Alignment argument to IRBuilder CreateAtomicRMW and CreateAtomicCmpXchg.James Y Knight1-1/+1
And then push those change throughout LLVM. Keep the old signature in Clang's CGBuilder for now -- that will be updated in a follow-on patch (D97224). The MLIR LLVM-IR dialect is not updated to support the new alignment attribute, but preserves its existing behavior. Differential Revision: https://reviews.llvm.org/D97223
2021-02-22Add auto-upgrade support for annotation intrinsicsAndy Kaylor1-0/+42
The llvm.ptr.annotation and llvm.var.annotation intrinsics were changed since the 11.0 release to add an additional parameter. This patch auto-upgrades IR containing the four-parameter versions of these intrinsics, adding a null pointer as the fifth argument. Differential Revision: https://reviews.llvm.org/D95993
2021-02-12Fix layering after ed4718eccb12.James Y Knight1-2/+1
That commit added a dependency from IR to Analysis, which isn't allowed. Fix it by duplicating a string constant.
2021-02-12[ObjC][ARC] Use operand bundle 'clang.arc.attachedcall' instead ofAkira Hatanaka1-2/+3
explicitly emitting retainRV or claimRV calls in the IR Background: This fixes a longstanding problem where llvm breaks ARC's autorelease optimization (see the link below) by separating calls from the marker instructions or retainRV/claimRV calls. The backend changes are in https://reviews.llvm.org/D92569. https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue What this patch does to fix the problem: - The front-end adds operand bundle "clang.arc.attachedcall" to calls, which indicates the call is implicitly followed by a marker instruction and an implicit retainRV/claimRV call that consumes the call result. In addition, it emits a call to @llvm.objc.clang.arc.noop.use, which consumes the call result, to prevent the middle-end passes from changing the return type of the called function. This is currently done only when the target is arm64 and the optimization level is higher than -O0. - ARC optimizer temporarily emits retainRV/claimRV calls after the calls with the operand bundle in the IR and removes the inserted calls after processing the function. - ARC contract pass emits retainRV/claimRV calls after the call with the operand bundle. It doesn't remove the operand bundle on the call since the backend needs it to emit the marker instruction. The retainRV and claimRV calls are emitted late in the pipeline to prevent optimization passes from transforming the IR in a way that makes it harder for the ARC middle-end passes to figure out the def-use relationship between the call and the retainRV/claimRV calls (which is the cause of PR31925). - The function inliner removes an autoreleaseRV call in the callee if nothing in the callee prevents it from being paired up with the retainRV/claimRV call in the caller. It then inserts a release call if claimRV is attached to the call since autoreleaseRV+claimRV is equivalent to a release. If it cannot find an autoreleaseRV call, it tries to transfer the operand bundle to a function call in the callee. This is important since the ARC optimizer can remove the autoreleaseRV returning the callee result, which makes it impossible to pair it up with the retainRV/claimRV call in the caller. If that fails, it simply emits a retain call in the IR if retainRV is attached to the call and does nothing if claimRV is attached to it. - SCCP refrains from replacing the return value of a call with a constant value if the call has the operand bundle. This ensures the call always has at least one user (the call to @llvm.objc.clang.arc.noop.use). - This patch also fixes a bug in replaceUsesOfNonProtoConstant where multiple operand bundles of the same kind were being added to a call. Future work: - Use the operand bundle on x86-64. - Fix the auto upgrader to convert call+retainRV/claimRV pairs into calls with the operand bundles. rdar://71443534 Differential Revision: https://reviews.llvm.org/D92808
2021-02-05Revert "[ObjC][ARC] Use operand bundle 'clang.arc.rv' instead of explicitly"Akira Hatanaka1-3/+2
This reverts commit 3fe3946d9a958b7af6130241996d9cfcecf559d4. The commit violates layering by including a header from Analysis in lib/IR/AutoUpgrade.cpp.
2021-02-05[ObjC][ARC] Use operand bundle 'clang.arc.rv' instead of explicitlyAkira Hatanaka1-2/+3
emitting retainRV or claimRV calls in the IR Background: This patch makes changes to the front-end and middle-end that are needed to fix a longstanding problem where llvm breaks ARC's autorelease optimization (see the link below) by separating calls from the marker instructions or retainRV/claimRV calls. The backend changes are in https://reviews.llvm.org/D92569. https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue What this patch does to fix the problem: - The front-end adds operand bundle "clang.arc.rv" to calls, which indicates the call is implicitly followed by a marker instruction and an implicit retainRV/claimRV call that consumes the call result. In addition, it emits a call to @llvm.objc.clang.arc.noop.use, which consumes the call result, to prevent the middle-end passes from changing the return type of the called function. This is currently done only when the target is arm64 and the optimization level is higher than -O0. - ARC optimizer temporarily emits retainRV/claimRV calls after the calls with the operand bundle in the IR and removes the inserted calls after processing the function. - ARC contract pass emits retainRV/claimRV calls after the call with the operand bundle. It doesn't remove the operand bundle on the call since the backend needs it to emit the marker instruction. The retainRV and claimRV calls are emitted late in the pipeline to prevent optimization passes from transforming the IR in a way that makes it harder for the ARC middle-end passes to figure out the def-use relationship between the call and the retainRV/claimRV calls (which is the cause of PR31925). - The function inliner removes an autoreleaseRV call in the callee if nothing in the callee prevents it from being paired up with the retainRV/claimRV call in the caller. It then inserts a release call if the call is annotated with claimRV since autoreleaseRV+claimRV is equivalent to a release. If it cannot find an autoreleaseRV call, it tries to transfer the operand bundle to a function call in the callee. This is important since ARC optimizer can remove the autoreleaseRV returning the callee result, which makes it impossible to pair it up with the retainRV/claimRV call in the caller. If that fails, it simply emits a retain call in the IR if the implicit call is a call to retainRV and does nothing if it's a call to claimRV. Future work: - Use the operand bundle on x86-64. - Fix the auto upgrader to convert call+retainRV/claimRV pairs into calls annotated with the operand bundles. rdar://71443534 Differential Revision: https://reviews.llvm.org/D92808
2021-01-25Revert "[ObjC][ARC] Annotate calls with attributes instead of emitting retainRV"Richard Smith1-3/+2
This reverts commit 53176c168061d6f26dcf3ce4fa59288b7d67255e, which introduceed a layering violation. LLVM's IR library can't include headers from Analysis.
2021-01-25[ObjC][ARC] Annotate calls with attributes instead of emitting retainRVAkira Hatanaka1-2/+3
or claimRV calls in the IR Background: This patch makes changes to the front-end and middle-end that are needed to fix a longstanding problem where llvm breaks ARC's autorelease optimization (see the link below) by separating calls from the marker instructions or retainRV/claimRV calls. The backend changes are in https://reviews.llvm.org/D92569. https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue What this patch does to fix the problem: - The front-end annotates calls with attribute "clang.arc.rv"="retain" or "clang.arc.rv"="claim", which indicates the call is implicitly followed by a marker instruction and a retainRV/claimRV call that consumes the call result. This is currently done only when the target is arm64 and the optimization level is higher than -O0. - ARC optimizer temporarily emits retainRV/claimRV calls after the annotated calls in the IR and removes the inserted calls after processing the function. - ARC contract pass emits retainRV/claimRV calls after the annotated calls. It doesn't remove the attribute on the call since the backend needs it to emit the marker instruction. The retainRV/claimRV calls are emitted late in the pipeline to prevent optimization passes from transforming the IR in a way that makes it harder for the ARC middle-end passes to figure out the def-use relationship between the call and the retainRV/claimRV calls (which is the cause of PR31925). - The function inliner removes the autoreleaseRV call in the callee that returns the result if nothing in the callee prevents it from being paired up with the calls annotated with "clang.arc.rv"="retain/claim" in the caller. If the call is annotated with "claim", a release call is inserted since autoreleaseRV+claimRV is equivalent to a release. If it cannot find an autoreleaseRV call, it tries to transfer the attributes to a function call in the callee. This is important since ARC optimizer can remove the autoreleaseRV call returning the callee result, which makes it impossible to pair it up with the retainRV or claimRV call in the caller. If that fails, it simply emits a retain call in the IR if the call is annotated with "retain" and does nothing if it's annotated with "claim". - This patch teaches dead argument elimination pass not to change the return type of a function if any of the calls to the function are annotated with attribute "clang.arc.rv". This is necessary since the pass can incorrectly determine nothing in the IR uses the function return, which can happen since the front-end no longer explicitly emits retainRV/claimRV calls in the IR, and change its return type to 'void'. Future work: - Use the attribute on x86-64. - Fix the auto upgrader to convert call+retainRV/claimRV pairs into calls annotated with the attributes. rdar://71443534 Differential Revision: https://reviews.llvm.org/D92808
2021-01-14[llvm] Remove redundant return and continue statements (NFC)Kazu Hirata1-1/+0
Identified with readability-redundant-control-flow.
2021-01-10[STLExtras] Use return type from operator* of the wrapped iter.Florian Hahn1-4/+4
Currently make_early_inc_range cannot be used with iterators with operator* implementations that do not return a reference. Most notably in the LLVM codebase, this means the User iterator ranges cannot be used with make_early_inc_range, which slightly simplifies iterating over ranges while elements are removed. Instead of directly using BaseT::reference as return type of operator*, this patch uses decltype to get the actual return type of the operator* implementation in WrappedIteratorT. This patch also updates a few places to use make use of make_early_inc_range. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D93992
2020-12-30clang-format, address warningsJuneyoung Lee1-5/+4
2020-12-30Use unary CreateShuffleVector if possibleJuneyoung Lee1-10/+8
As mentioned in D93793, there are quite a few places where unary `IRBuilder::CreateShuffleVector(X, Mask)` can be used instead of `IRBuilder::CreateShuffleVector(X, Undef, Mask)`. Let's update them. Actually, it would have been more natural if the patches were made in this order: (1) let them use unary CreateShuffleVector first (2) update IRBuilder::CreateShuffleVector to use poison as a placeholder value (D93793) The order is swapped, but in terms of correctness it is still fine. Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D93923
2020-12-14OpaquePtr: Require byval on x86_intrcc parameter 0Matt Arsenault1-0/+7
Currently the backend special cases x86_intrcc and treats the first parameter as byval. Make the IR require byval for this parameter to remove this special case, and avoid the dependence on the pointee element type. Fixes bug 46672. I'm not sure the IR is enforcing all the calling convention constraints. clang seems to ignore the attribute for empty parameter lists, but the IR tolerates it.
2020-11-20[AMDGPU] Set the default globals address space to 1Alex Richardson1-2/+8
This will ensure that passes that add new global variables will create them in address space 1 once the passes have been updated to no longer default to the implicit address space zero. This also changes AutoUpgrade.cpp to add -G1 to the DataLayout if it wasn't already to present to ensure bitcode backwards compatibility. Reviewed by: arsenm Differential Revision: https://reviews.llvm.org/D84345
2020-10-07[llvm][mlir] Promote the experimental reduction intrinsics to be first class ↵Amara Emerson1-27/+30
intrinsics. This change renames the intrinsics to not have "experimental" in the name. The autoupgrader will handle legacy intrinsics. Relevant ML thread: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140729.html Differential Revision: https://reviews.llvm.org/D88787
2020-09-15[X86] Update SSE/AVX integer MINMAX intrinsics to emit llvm.smax.* etc. ↵Simon Pilgrim1-17/+4
(PR46851) We're now getting close to having the necessary analysis/combines etc. for the new generic llvm smax/smin/umax/umin intrinsics. This patch updates the SSE/AVX integer MINMAX intrinsics to emit the generic equivalents instead of the icmp+select code pattern. Differential Revision: https://reviews.llvm.org/D87603
2020-09-07[X86] Replace UpgradeX86AddSubSatIntrinsics with UpgradeX86BinaryIntrinsics ↵Simon Pilgrim1-15/+11
generic helper. NFCI. Feed the Intrinsic::ID value directly instead of via the IsSigned/IsAddition bool flags.
2020-09-07[X86] Auto upgrade SSE/AVX PABS intrinsics to generic Intrinsic::absSimon Pilgrim1-8/+4
Minor followup to D87101, we were expanding this to a neg+icmp+select pattern like we were in CGBuiltin
2020-08-27[SVE] Remove calls to VectorType::getNumElements from IRChristopher Tetreault1-42/+51
Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D81500
2020-08-27[ARM][BFloat16] Change types of some Arm and AArch64 bf16 intrinsicsMikhail Maltsev1-0/+81
This patch adjusts the following ARM/AArch64 LLVM IR intrinsics: - neon_bfmmla - neon_bfmlalb - neon_bfmlalt so that they take and return bf16 and float types. Previously these intrinsics used <8 x i8> and <4 x i8> vectors (a rudiment from implementation lacking bf16 IR type). The neon_vbfdot[q] intrinsics are adjusted similarly. This change required some additional selection patterns for vbfdot itself and also for vector shuffles (in a previous patch) because of SelectionDAG transformations kicking in and mangling the original code. This patch makes the generated IR cleaner (less useless bitcasts are produced), but it does not affect the final assembly. Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D86146
2020-08-19[X86][AutoUpgrade] Simplify string management in UpgradeDataLayoutString a ↵Craig Topper1-4/+2
bit. NFCI We don't need a std::string for a literal string, we can use a StringRef. The addition of StringRefs produces a Twine that we can just call str() without converting to a SmallString ourselves. Twine will do that internally.
2020-08-11[AutoUpgrade] Simplify codeBenjamin Kramer1-16/+4
No need to set the name on an instruction that's going away, just move it from the old instruction to the new one.
2020-08-11[X86][FPEnv] Fix a use after freeBenjamin Kramer1-1/+1
Found by asan!
2020-08-11[X86][FPEnv] Teach X86 mask compare intrinsics to respect strict FP semantics.Wang, Pengfei1-18/+71
When we use mask compare intrinsics under strict FP option, the masked elements shouldn't raise any exception. So, we cann't replace the intrinsic with a full compare + "and" operation. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D85385
2020-08-06[X86] getX86MaskVec - replace mask limit from NumElts < 8 with NumElts <= 4Simon Pilgrim1-6/+6
As noted on PR46885, the number of mask elements should always be a power of 2, so to fix the static analyzer warning we are better off replacing the condition to <= 4, and I've added a pow2 assertion as well.
2020-07-09Make helpers static. NFC.Benjamin Kramer1-2/+3
2020-07-03[Alignment][NFC] Use proper getter to retrieve alignment from ConstantInt ↵Guillaume Chatelet1-2/+2
and ConstantSDNode This patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Differential Revision: https://reviews.llvm.org/D83082
2020-06-15[strictfp] Replace dangling strictfp attrs with nobuiltinKevin P. Neal1-0/+37
In preparation for a patch that will enforce new rules for the usage of the strictfp attribute, this patch introduces auto-upgrade behavior that will replace the strictfp attribute on callsites with nobuiltin if the enclosing function declaration doesn't also have the strictfp attribute. This auto-upgrade isn't being performed on .ll files because that would prevent us from writing a test for the forthcoming verifier behavior. Differential Revision: https://reviews.llvm.org/D70096
2020-06-03[SVE] Eliminate calls to default-false VectorType::get() from IRChristopher Tetreault1-15/+16
Reviewers: efriedma, kmclaughlin, sdesmalen, dexonsmith, dblaikie Reviewed By: efriedma Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80261
2020-05-15[IR] Convert null-pointer-is-valid into an enum attributeNikita Popov1-2/+12
The "null-pointer-is-valid" attribute needs to be checked by many pointer-related combines. To make the check more efficient, convert it from a string into an enum attribute. In the future, this attribute may be replaced with data layout properties. Differential Revision: https://reviews.llvm.org/D78862
2020-04-15Pass shufflevector indices as int instead of unsigned.Benjamin Kramer1-26/+24
No functionality change intended.
2020-04-14[SVE] Remove calls to getBitWidth from IRChristopher Tetreault1-12/+15
Reviewers: efriedma, sdesmalen, RKSimon, majnemer Reviewed By: majnemer Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77897
2020-04-10Clean up usages of asserting vector getters in TypeChristopher Tetreault1-56/+60
Summary: Remove usages of asserting vector getters in Type in preparation for the VectorType refactor. The existence of these functions complicates the refactor while adding little value. Reviewers: dexonsmith, sdesmalen, efriedma Reviewed By: efriedma Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77276
2020-03-31Remove "mask" operand from shufflevector.Eli Friedman1-4/+5
Instead, represent the mask as out-of-line data in the instruction. This should be more efficient in the places that currently use getShuffleVector(), and paves the way for further changes to add new shuffles for scalable vectors. This doesn't change the syntax in textual IR. And I don't currently plan to change the bitcode encoding in this patch, although we'll probably need to do something once we extend shufflevector for scalable types. I expect that once this is finished, we can then replace the raw "mask" with something more appropriate for scalable vectors. Not sure exactly what this looks like at the moment, but there are a few different ways we could handle it. Maybe we could try to describe specific shuffles. Or maybe we could define it in terms of a function to convert a fixed-length array into an appropriate scalable vector, using a "step", or something like that. Differential Revision: https://reviews.llvm.org/D72467
2020-03-24[X86] Disable autoupgrade support for avx512.mask.broadcasti32x2.* and ↵Craig Topper1-2/+8
avx512.mask.broadcastf32x2.*. These intrinsics take a v4i32/v4f32 input and are supposed to broadcast elements 0 and 1. Instead the autoupgrade code was broadcasting elements 0, 1, 2, and 3. I could fix the autoupgrade, but since its been broken for years it seemed better just to steer anyone still trying to use it away completely.
2020-03-11Fix conflict value for metadata "Objective-C Garbage Collection" in the mix ↵Jin Lin1-0/+41
of swift and Objective-C bitcode Summary: The change is to fix conflict value for metadata "Objective-C Garbage Collection" in the mix of swift and Objective-C bitcode. The purpose is to provide the support of LTO for swift and Objective-C mixed project. Reviewers: rjmccall, ahatanak, steven_wu Reviewed By: rjmccall, steven_wu Subscribers: manmanren, mehdi_amini, hiraditya, dexonsmith, llvm-commits, jinlin Tags: #llvm Differential Revision: https://reviews.llvm.org/D71219
2020-02-29[X86][F16C] Remove cvtph2ps intrinsics and use generic half2float conversion ↵Simon Pilgrim1-0/+20
(PR37554) This removes everything but int_x86_avx512_mask_vcvtph2ps_512 which provides the SAE variant, but even this can use the fpext generic if the rounding control is the default. Differential Revision: https://reviews.llvm.org/D75162
2020-02-24[X86] Add back fmaddsub intrinsics to work towards fixing the strict fp ↵Craig Topper1-22/+17
implementation Previously we emitted an fmadd and a fmadd+fneg and combined them with a shufflevector. But this doesn't follow the correct exception behavior for unselected elements so the backend can't merge them into the fmaddsub/fmsubadd instructions. This patch restores the the fmaddsub intrinsics so we don't have two arithmetic operations. We lose out on optimization opportunity in the non-strict FP case, but I don't think this is a big loss. If someone gives us a test case we can look into adding instcombine/dagcombine improvements. I'd rather not have the frontend do completely different things for strict and non-strict. This still has problems because target specific intrinsics don't support strict semantics yet. We also still have all of the problems with masking. But we at least generate the right instruction in constrained mode now. Differential Revision: https://reviews.llvm.org/D74268
2020-02-07[X86] Correct the implementation of the avx512 masked fmsubadd autoupgrade ↵Craig Topper1-2/+1
code to not leave the negate unconnected. This was causing us to generate fmaddsub instead of fmsubadd if rounding control is not 4.
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-5/+5
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
generated by cgit v1.1 at 2025-09-29 18:56:05 +0000