aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/IR/InstructionsTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-06-25[llvm] Don't use Optional::{hasValue,getValue} (NFC)Kazu Hirata1-2/+2
2022-04-30[CAPI] Expose CastInst::getCastOpcode in C APIJack Andersen1-0/+62
Reviewed By: deadalnix Differential Revision: https://reviews.llvm.org/D91514
2022-03-31Mapping of FP operations to constrained intrinsicsSerge Pavlov1-0/+54
A new function 'getConstrainedIntrinsic' is added, which for any gived instruction returns id of the corresponding constrained intrinsic. If there is no constrained counterpart for the instruction or the instruction is already a constrained intrinsic, the function returns zero. This is recommit of 115b3ace369254f573ca28934ef30ab9d8f497ef, reverted in 8160dd582b67430a5c24c836a57ae3c15cfa973c. Differential Revision: https://reviews.llvm.org/D69562
2022-03-30Revert "Mapping of FP operations to constrained intrinsics"Serge Pavlov1-54/+0
This reverts commit 115b3ace369254f573ca28934ef30ab9d8f497ef. Starting from this commit the buildbot sanitizer-x86_64-linux-bootstrap-msan starts failing (build 10071). Reverted for investigation.
2022-03-30Mapping of FP operations to constrained intrinsicsSerge Pavlov1-0/+54
A new function 'getConstrainedIntrinsic' is added, which for any gived instruction returns id of the corresponding constrained intrinsic. If there is no constrained counterpart for the instruction or the instruction is already a constrained intrinsic, the function returns zero. Differential Revision: https://reviews.llvm.org/D69562
2022-01-10Use a sorted array instead of a map to store AttrBuilder string attributesSerge Guelton1-3/+3
Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2021-11-07[IR][ShuffleVector] Fix Wdangling-else warning in InstructionsTestLuke Benes1-1/+2
Fix a dangling else that gcc-11 warned about. The EXPECT_EQ macro expands to an if-else, so the whole construction contains a hidden dangling else. Differential Revision: https://reviews.llvm.org/D113346
2021-11-06[IR] Improve member `ShuffleVectorInst::isReplicationMask()`Roman Lebedev1-0/+10
When we have an actual shuffle, we can impose the additional restriction that the mask replicates the elements of the first operand, so we know the replication factor as a ratio of output and op0 vector sizes.
2021-11-05[NFCI] InstructionTest: trim ↵Roman Lebedev1-2/+2
`InstructionsTest.ShuffleMaskIsReplicationMask_*` complexity These tests have pretty high O() complexity due to their nature, which leads to potentially-long runtimes. While in release build for me they took ~1 and ~2 sec, as noted in https://reviews.llvm.org/D113214#inline-1080479 they take minutes in debug build. Fine-tune the amount of permutations they deal with, without affecting the test coverage. After this, they take <~10ms each for me (in release build), hopefully that is good-enough for debug build too.
2021-11-05[IR][ShuffleVector] Introduce `isReplicationMask()` matcherRoman Lebedev1-1/+89
Avid readers of this saga may recall from previous installments, that replication mask replicates (lol) each of the `VF` elements in a vector `ReplicationFactor` times. For example, the mask for `ReplicationFactor=3` and `VF=4` is: `<0,0,0,1,1,1,2,2,2,3,3,3>`. More importantly, replication mask is used by LoopVectorizer when using masked interleaved memory operations. As discussed in previous installments, while it is used by LV, and we **seem** to support masked interleaved memory operations on X86, it's support in cost model leaves a lot to be desired: until basically yesterday even for AVX512 we had no cost model for it. As it has been witnessed in the recent AVX2 `X86TTIImpl::getInterleavedMemoryOpCost()` costmodel patches, while it is hard-enough to query the cost of a particular assembly sequence [from llvm-mca], afterwards the check lines LV costmodel tests must be updated manually. This is, at the very least, boring. Okay, now we have decent costmodel coverage for interleaving shuffles, but now basically the same mind-killing sequence has to be performed for replication mask. I think we can improve at least the second half of the problem, by teaching the `TargetTransformInfoImplCRTPBase::getUserCost()` to recognize `Instruction::ShuffleVector` that are repetition masks, adding exhaustive test coverage using `-cost-model -analyze` + `utils/update_analyze_test_checks.py` This way we can have good exhaustive coverage for cost model, and only basic coverage for the LV costmodel. This patch adds precise undef-aware `isReplicationMask()`, with exhaustive test coverage. * `InstructionsTest.ShuffleMaskIsReplicationMask` shows that it correctly detects all the known masks. * `InstructionsTest.ShuffleMaskIsReplicationMask_undef` shows that replacing some mask elements in a known replication mask still allows us to recognize it as a replication mask. Note, with enough undef elts, we may detect a different tuple. * `InstructionsTest.ShuffleMaskIsReplicationMask_Exhaustive_Correctness` shows that if we detected the replication mask with given params, then if we actually generate a true replication mask with said params, it matches element-wise ignoring undef mask elements. Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D113214
2021-10-05[llvm] Migrate from getNumArgOperands to arg_size (NFC)Kazu Hirata1-2/+2
Note that getNumArgOperands is considered a legacy name. See llvm/include/llvm/IR/InstrTypes.h for details.
2021-09-30[llvm] Migrate from arg_operands to args (NFC)Kazu Hirata1-2/+2
Note that arg_operands is considered a legacy name. See llvm/include/llvm/IR/InstrTypes.h for details.
2021-08-17[NFC] More get/removeAttribute() cleanupArthur Eubanks1-2/+1
2020-12-10[CallBase] Add hasRetAttr version that takes StringRef.Florian Hahn1-0/+5
This makes it slightly easier to deal with custom attributes and CallBase already provides hasFnAttr versions that support both AttrKind and StringRef arguments in a similar fashion. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D92567
2020-12-09[IR] Support scalable vectors in CastInst::CreatePointerCastCullen Rhodes1-0/+8
Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D92482
2020-12-08[IR] Remove CastInst::isCastable since it is not usedCullen Rhodes1-6/+0
It was removed back in 2013 (f63dfbb) by Matt Arsenault but then reverted since DragonEgg used it, but that project is no longer maintained. Reviewed By: ldionne, dexonsmith Differential Revision: https://reviews.llvm.org/D92571
2020-12-07[IR] Bail out for scalable vectors in ShuffleVectorInst::isConcatCullen Rhodes1-0/+11
Shuffle mask for concat can't be expressed for scalable vectors, so we should bail out. A test has been added that previously crashed, also tested isIdentityWithPadding and isIdentityWithExtract where we already bail out. Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D92475
2020-12-07[IR] Support scalable vectors in ShuffleVectorInst::increasesLengthCullen Rhodes1-0/+12
Since the length of the llvm::SmallVector shufflemask is related to the minimum number of elements in a scalable vector, it is fine to just get the Min field of the ElementCount. This is already done for the similar function changesLength, tests have been added for both. Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D92472
2020-12-04[IR] Disallow scalable vectors in ShuffleVectorInst::isExtractSubvectorMaskCullen Rhodes1-0/+11
It's not possible to express an extract subvector shuffle mask for a scalable vector. Reviewed By: david-arm Differential Revision: https://reviews.llvm.org/D92312
2020-12-02[InstructionsTest] NFC: Replace VectorType::get(.., .., true) with ↵Cullen Rhodes1-8/+8
ScalableVectorType::get Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D92467
2020-11-27[AllocaInst] Update `getAllocationSizeInBits` to return `TypeSize`.Francesco Petrogalli1-0/+40
Reviewed By: peterwaller-arm, sdesmalen Differential Revision: https://reviews.llvm.org/D92020
2020-11-24Make CallInst::updateProfWeight emit i32 weights instead of i64Arthur Eubanks1-0/+24
Typically branch_weights are i32, not i64. This fixes entry_counts_cold.ll under NPM. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D90539
2020-09-24[Instruction] Add dropLocation and updateLocationAfterHoist helpersVedant Kumar1-0/+72
Introduce a helper which can be used to update the debug location of an Instruction after the instruction is hoisted. This can be used to safely drop a source location as recommended by the docs. For more context, see the discussion in https://reviews.llvm.org/D60913. Differential Revision: https://reviews.llvm.org/D85670
2020-08-11Revert "[Instruction] Add updateLocationAfterHoist helper"Vedant Kumar1-47/+0
This reverts commit 4a646ca9e2caf70d6312714770f516fb83b7e3cb. This is causing some bots to fail with "!dbg attachment points at wrong subprogram for function", like: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/67958/steps/stage%201%20check/logs/stdio
2020-08-11[Instruction] Add updateLocationAfterHoist helperVedant Kumar1-0/+47
Introduce a helper on Instruction which can be used to update the debug location after hoisting. Use this in GVN and LICM, where we were mistakenly introducing new line 0 locations after hoisting (the docs recommend dropping the location in this case). For more context, see the discussion in https://reviews.llvm.org/D60913. Differential Revision: https://reviews.llvm.org/D85670
2020-06-16[SVE] Deprecate default false variant of VectorType::getChristopher Tetreault1-17/+17
Reviewers: efriedma, fpetrogalli, kmclaughlin, huntergr Reviewed By: fpetrogalli Subscribers: cfe-commits, tschuett, rkruppe, psnobl, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D80342
2020-03-30[llvm][IR][CastInst] Update `castIsValid` for scalable vectors.Francesco Petrogalli1-0/+79
Reviewers: sdesmalen Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76738
2019-12-10[IR] allow undefined elements when checking for splat constantsSanjay Patel1-0/+40
This mimics the related call in SDAG. The caller is responsible for ensuring that undef values are propagated safely.
2019-10-30[IR] Allow fast math flags on calls with floating point array type.Jay Foad1-0/+54
Summary: This extends the rules for when a call instruction is deemed to be an FPMathOperator, which is based on the type of the call (i.e. the return type of the function being called). Previously we only allowed floating-point and vector-of-floating-point types. Now we also allow arrays (nested to any depth) of floating-point and vector-of-floating-point types. This was motivated by llpc, the pipeline compiler for AMD GPUs (https://github.com/GPUOpen-Drivers/llpc). llpc has many math library functions that operate on vectors, typically represented as <4 x float>, and some that operate on matrices, typically represented as [4 x <4 x float>], and it's useful to be able to decorate calls to all of them with fast math flags. Reviewers: spatel, wristow, arsenm, hfinkel, aemerson, efriedma, cameron.mcinally, mcberg2017, jmolloy Subscribers: wdng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69161
2019-10-14[ASan] Fix IRTests/InstructionsTest.UnaryOperatorCameron McInally1-0/+1
Fix ASan regression from r374782. llvm-svn: 374808
2019-10-14[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally1-0/+15
Reapply r374240 with fix for Ocaml test, namely Bindings/OCaml/core.ml. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374782
2019-10-10Revert "[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator"Dmitri Gribenko1-15/+0
This reverts commit r374240. It broke OCaml tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19014 llvm-svn: 374354
2019-10-09[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally1-0/+15
Also update Clang to call Builder.CreateFNeg(...) for UnaryMinus. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374240
2019-09-25[IR] allow fast-math-flags on phi of FP values (2nd try)Sanjay Patel1-2/+5
The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 <https://reviews.llvm.org/D61917> As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372878
2019-09-25Revert [IR] allow fast-math-flags on phi of FP valuesSanjay Patel1-5/+2
This reverts r372866 (git commit dec03223a97af0e4dfcb23da55c0f7f8c9b62d00) llvm-svn: 372868
2019-09-25[IR] allow fast-math-flags on phi of FP valuesSanjay Patel1-2/+5
The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372866
2019-09-06[IR] CallBrInst: scan+update arg list when indirect dest list changesNick Desaulniers1-0/+51
Summary: There's an unspoken invariant of callbr that the list of BlockAddress Constants in the "function args" list match the BasicBlocks in the "other labels" list. (This invariant is being added to the LangRef in https://reviews.llvm.org/D67196). When modifying the any of the indirect destinations of a callbr instruction (possible jump targets), we need to update the function arguments if the argument is a BlockAddress whose BasicBlock refers to the indirect destination BasicBlock being replaced. Otherwise, many transforms that modify successors will end up violating that invariant. A recent change to the arm64 Linux kernel exposed this bug, which prevents the kernel from booting. I considered maintaining a mapping from indirect destination BasicBlock to argument operand BlockAddress, but this ends up being a one to potentially many (though usually one) mapping. Also, the list of arguments to a function (or more typically inline assembly) ends up being less than 10. The implementation is significantly simpler to just rescan the full list of arguments. Because of the one to potentially many relationship, the full arg list must be scanned (we can't stop at the first instance). Thanks to the following folks that reported the issue and helped debug it: * Nathan Chancellor * Will Deacon * Andrew Murray * Craig Topper Link: https://bugs.llvm.org/show_bug.cgi?id=43222 Link: https://github.com/ClangBuiltLinux/linux/issues/649 Link: https://lists.infradead.org/pipermail/linux-arm-kernel/2019-September/678330.html Reviewers: craig.topper, chandlerc Reviewed By: craig.topper Subscribers: void, javed.absar, kristof.beyls, hiraditya, llvm-commits, nathanchance, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D67252 llvm-svn: 371262
2019-07-09Prepare for making SwitchInstProfUpdateWrapper strictYevgeny Rouban1-38/+0
This patch removes the test part that relates to the non-strict behavior of SwitchInstProfUpdateWrapper and changes the assertion to llvm_unreachable() to allow the check in release builds. This patch prepares SwitchInstProfUpdateWrapper to become strict with one line change. That is need to revert it easily if any failure will arise. llvm-svn: 365439
2019-06-07[IR] Add UnaryOperator::CreateFNegFMF(...)Cameron McInally1-0/+18
Differential Revision: https://reviews.llvm.org/D62705 llvm-svn: 362828
2019-06-04Make SwitchInstProfUpdateWrapper saferYevgeny Rouban1-0/+79
While prof branch_weights inconsistencies are being fixed patch by patch (pass by pass) we need SwitchInstProfUpdateWrapper to be safe with respect to inconsistent metadata that can come from passes that have not been fixed yet. See the bug found by @nikic in https://reviews.llvm.org/D62126. This patch introduces one more state (called Invalid) to the wrapper class that allows users to work with the underlying SwitchInst ignoring the prof metadata changes. Created a unit test for the SwitchInstProfUpdateWrapper class. Reviewers: davidx, nikic, eraman, reames, chandlerc Reviewed By: davidx Differential Revision: https://reviews.llvm.org/D62656 llvm-svn: 362473
2019-03-05PHI nodes are not `FPMathOperator` sSanjoy Das1-0/+9
Reviewers: chandlerc, arsenm Reviewed By: arsenm Subscribers: wdng, arsenm, mcrosier, jlebar, bixia, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58887 llvm-svn: 355362
2019-02-01[opaque pointer types] Pass value type to GetElementPtr creation.James Y Knight1-1/+2
This cleans up all GetElementPtr creation in LLVM to explicitly pass a value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57173 llvm-svn: 352913
2019-02-01[opaque pointer types] Pass function types to InvokeInst creation.James Y Knight1-3/+4
This cleans up all InvokeInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57171 llvm-svn: 352910
2019-02-01[opaque pointer types] Pass function types to CallInst creation.James Y Knight1-4/+5
This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-09-20[IR] add shuffle query for vector concatenationSanjay Patel1-0/+45
This can be used for combining and in the vectorizers/cost models. llvm-svn: 342653
2018-09-20[IR] reduce duplication in unittest for shuffles; NFCSanjay Patel1-16/+12
llvm-svn: 342650
2018-08-30[IR] add shuffle queries for identity extend/extract Sanjay Patel1-0/+72
This was one of the potential follow-ups suggested in D48236, and these will be used to make matching the patterns in PR38691 cleaner: https://bugs.llvm.org/show_bug.cgi?id=38691 About the vocabulary: in the DAG, these would be concat_vector with an undef operand or extract_subvector. Alternate names are discussed in the review, but I think these are familiar/good enough to proceed. Once we have uses of them in code, we might adjust if there are better options. https://reviews.llvm.org/D51392 llvm-svn: 341075
2018-06-26Rename skipDebugInfo -> skipDebugIntrinsics, NFCVedant Kumar1-1/+1
This addresses post-commit feedback about the name 'skipDebugInfo' being misleading. This name could be interpreted as meaning 'a function that skips instructions with debug locations'. The new name, 'skipDebugIntrinsics', makes it clear that this function only skips debug info intrinsics. Thanks to Adrian Prantl for pointing this out! llvm-svn: 335667
2018-06-19[IR] Introduce helpers to skip debug instructions (NFC)Vedant Kumar1-0/+49
This patch introduces two helpers to make it easier to ignore debug intrinsics: - Instruction::getNextNonDebugInstruction() This is just like Instruction::getNextNode(), except that it skips debug info. - skipDebugInfo(BasicBlock::iterator) A free function which advances a BasicBlock iterator past any debug info. This is a no-op when the iterator already points to a non-debug instruction. Part of: llvm.org/PR37728 Related to: https://reviews.llvm.org/D47874 Differential Revision: https://reviews.llvm.org/D48305 llvm-svn: 335083
generated by cgit v1.1 at 2025-09-29 07:55:43 +0000