aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/Constants.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-09-29[InstCombine] visitTrunc - trunc (lshr (sext A), C) --> (ashr A, C) ↵Simon Pilgrim1-0/+5
non-uniform support This came from @lebedev.ri's suggestion to use m_SpecificInt_ICMP for D88429 - since I was going to change the m_APInt to m_Constant for that patch I thought I would do it for the only other user of the APInt first. I've added a ConstantExpr::getUMin helper - its trivial to add UMAX/SMIN/SMAX but thought I'd wait until we have use cases. Differential Revision: https://reviews.llvm.org/D88475
2020-08-28[SVE] Make ElementCount members privateDavid Sherwood1-6/+6
This patch changes ElementCount so that the Min and Scalable members are now private and can only be accessed via the get functions getKnownMinValue() and isScalable(). In addition I've added some other member functions for more commonly used operations. Hopefully this makes the class more useful and will reduce the need for calling getKnownMinValue(). Differential Revision: https://reviews.llvm.org/D86065
2020-08-27[SVE] Remove calls to VectorType::getNumElements from IRChristopher Tetreault1-14/+23
Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D81500
2020-08-21[Constants] Handle FNeg in getWithOperands.Florian Hahn1-0/+2
Currently ConstantExpr::getWithOperands does not handle FNeg and subsequently treats FNeg as binary operator, leading to an assertion failure or segmentation fault if built without assertions. Originally I reproduced this with llvm-dis on a bitcode file, which I unfortunately cannot share and also cannot really reduce. But PR45426 describes the same issue and has a reproducer with Clang, so I'll go with that. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D86274
2020-08-19Revert "Revert "[NFC][llvm] Make the contructors of `ElementCount` private.""Mehdi Amini1-2/+2
Was reverted because MLIR/Flang builds were broken, these APIs have been fixed in the meantime.
2020-08-19Revert "[NFC][llvm] Make the contructors of `ElementCount` private."Mehdi Amini1-2/+2
This reverts commit 264afb9e6aebc98c353644dd0700bec808501cab. (and dependent 6b742cc48 and fc53bd610f) MLIR/Flang are broken.
2020-08-19[NFC][llvm] Make the contructors of `ElementCount` private.Francesco Petrogalli1-2/+2
Differential Revision: https://reviews.llvm.org/D86120
2020-07-07[SVE] Make Constant::getSplatValue work for scalable vector splatsChristopher Tetreault1-0/+21
Summary: Make Constant::getSplatValue recognize scalable vector splats of the form created by ConstantVector::getSplat. Add unit test to verify that C == ConstantVector::getSplat(C)->getSplatValue() for fixed width and scalable vector splats Reviewers: efriedma, spatel, fpetrogalli, c-rhodes Reviewed By: efriedma Subscribers: sdesmalen, tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82416
2020-06-30[IR] Delete llvm::Constants using the correct type.Eli Friedman1-1/+68
In most cases, this doesn't have much impact: the destructors just call the base class destructor anyway. A few subclasses of ConstantExpr actually store non-trivial data, though. Make sure we clean up appropriately. This is sort of ugly, but I don't see a good alternative given the constraints. Issue found by asan buildbots running the testcase for D80330. Differential Revision: https://reviews.llvm.org/D82509
2020-06-23[IR] Prefer scalar type for struct indexes in GEP constant expressions.Eli Friedman1-5/+10
This has two advantages: one, it's simpler, and two, it doesn't require heroic pattern matching with scalable vectors. Also includes a small fix to DataLayout to allow the scalable vector testcase to work correctly. Differential Revision: https://reviews.llvm.org/D82061
2020-06-03[SVE] Eliminate calls to default-false VectorType::get() from IRChristopher Tetreault1-12/+12
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][BFloat] Add BFloat IR typeTies Stuij1-35/+71
Summary: The BFloat IR type is introduced to provide support for, initially, the BFloat16 datatype introduced with the Armv8.6 architecture (optional from Armv8.2 onwards). It has an 8-bit exponent and a 7-bit mantissa and behaves like an IEEE 754 floating point IR type. This is part of a patch series upstreaming Armv8.6 features. Subsequent patches will upstream intrinsics support and C-lang support for BFloat. Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, sdesmalen, deadalnix, ctetreau Subscribers: hiraditya, llvm-commits, danielkiss, arphaman, kristof.beyls, dexonsmith Tags: #llvm Differential Revision: https://reviews.llvm.org/D78190
2020-04-23[SVE] Remove calls to isScalable from IRChristopher Tetreault1-5/+5
Reviewers: efriedma, sdesmalen, dexonsmith, dblaikie Reviewed By: sdesmalen Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77691
2020-04-22[SVE] Add new VectorType subclassesChristopher Tetreault1-19/+20
Summary: Introduce new types for fixed width and scalable vectors. Does not remove getNumElements yet so as to not break code during transition period. Reviewers: deadalnix, efriedma, sdesmalen, craig.topper, huntergr Reviewed By: sdesmalen Subscribers: jholewinski, arsenm, jvesely, nhaehnle, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, kerbowa, Joonsoo, grosul1, frgossen, lldb-commits, tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm, #lldb Differential Revision: https://reviews.llvm.org/D77587
2020-04-22[NFC] Fix unused result of dyn_cast<VectorType> in non-assert buildSander de Smalen1-4/+4
2020-04-10Clean up usages of asserting vector getters in TypeChristopher Tetreault1-42/+51
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-04-06Remove SequentialType from the type heirarchy.Eli Friedman1-10/+23
Now that we have scalable vectors, there's a distinction that isn't getting captured in the original SequentialType: some vectors don't have a known element count, so counting the number of elements doesn't make sense. In some cases, there's a better way to express the commonality using other methods. If we're dealing with GEPs, there's GEP methods; if we're dealing with a ConstantDataSequential, we can query its element type directly. In the relatively few remaining cases, I just decided to write out the type checks. We're talking about relatively few places, and I think the abstraction doesn't really carry its weight. (See thread "[RFC] Refactor class hierarchy of VectorType in the IR" on llvmdev.) Differential Revision: https://reviews.llvm.org/D75661
2020-03-31Remove "mask" operand from shufflevector.Eli Friedman1-10/+19
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-30[ConstantFold][NFC] Compile time optimization for large vectorsThomas Raoux1-1/+9
Optimize the common case of splat vector constant. For large vector going through all elements is expensive. For splatr/broadcast cases we can skip going through all elements. Differential Revision: https://reviews.llvm.org/D76664
2020-03-18Remove CompositeType class.Eli Friedman1-5/+6
The existence of the class is more confusing than helpful, I think; the commonality is mostly just "GEP is legal", which can be queried using APIs on GetElementPtrInst. Differential Revision: https://reviews.llvm.org/D75660
2020-03-13[IR] Fix formatting. NFCCraig Topper1-1/+2
2020-03-12[ConstantFold][SVE] Fix constant folding for scalable vector compare ↵Huihui Zhang1-2/+2
instruction. Summary: Do not iterate on scalable vector. Also do not return constant scalable vector from ConstantInt::get(). Fix result type by using getElementCount() instead of getNumElements(). Reviewers: sdesmalen, efriedma, apazos, huntergr, willlovett Reviewed By: efriedma Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73753
2020-03-12[SVE] Update API ConstantVector::getSplat() to use ElementCount.Huihui Zhang1-33/+53
Summary: Support ConstantInt::get() and Constant::getAllOnesValue() for scalable vector type, this requires ConstantVector::getSplat() to take in 'ElementCount', instead of 'unsigned' number of element count. This change is needed for D73753. Reviewers: sdesmalen, efriedma, apazos, spatel, huntergr, willlovett Reviewed By: efriedma Subscribers: tschuett, hiraditya, rkruppe, psnobl, cfe-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74386
2020-02-18[NFC] Remove trailing spaceJim Lin1-5/+5
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h,td}
2020-01-17[IR] fix Constant::isElementWiseEqual() to allow for all undef elements compareSanjay Patel1-1/+2
We could argue that match() should be more flexible here, but I'm not sure what impact that would have on existing code.
2020-01-16[IR] fix crash in Constant::isElementWiseEqual() with FP typesSanjay Patel1-5/+10
We lifted this code from InstCombine for general usage in: rL369842 ...but it's not safe as-is. There are no existing users that can trigger this bug, but I discovered it via crashing several regression tests when trying to use it for select folding in InstSimplify. ICmp requires (vector) integer types, so give up on anything that's not integer or FP (pointers and ?) then bitcast the constants before trying the match. That matches the definition of "equal or undef" that I was looking for. If someone wants an FP-aware version of equality (deal with NaN, -0.0), that could be a different mode or different function. Differential Revision: https://reviews.llvm.org/D72784
2020-01-14[IR] fix potential crash in Constant::isElementWiseEqual()Sanjay Patel1-4/+9
There's only one user of this API currently, and it seems impossible that it would compare values with different types. But that's not true in general, so we need to make sure the types are the same. As denoted by the FIXME comments, we will also crash on FP values. That's what brought me here, but we can make that a follow-up patch.
2019-12-10[IR] allow undefined elements when checking for splat constantsSanjay Patel1-5/+22
This mimics the related call in SDAG. The caller is responsible for ensuring that undef values are propagated safely.
2019-12-09[ConstantFold][SVE] Fix constant folding for shufflevector.Eli Friedman1-1/+1
Don't try to fold away shuffles which can't be folded. Fix creation of shufflevector constant expressions. Differential Revision: https://reviews.llvm.org/D71147
2019-12-05[InstCombine] Extend `0 - (X sdiv C) -> (X sdiv -C)` fold to non-splat vectorsRoman Lebedev1-0/+24
Split off from https://reviews.llvm.org/D68408
2019-11-12Mark llvm::ConstantExpr::getAsInstruction as constAlex Denisov1-1/+1
Summary: getAsInstruction is the only non-const member method. It is impossible to enforce const-correctness because of it. Reviewers: jmolloy, majnemer Reviewed By: jmolloy Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70113
2019-11-04[IR] adjust assert when replacing undef elements in vector constantSanjay Patel1-1/+1
As noted in follow-up to: rGa1e8ad4f2fa7 It's not safe to assume that an element of the constant is always non-null. It's definitely not an expected case for the current instcombine user, but that may not hold if this function is eventually called from arbitrary places.
2019-10-29[IR] move/change null-check to assertSanjay Patel1-1/+2
This should trigger a dereference before null-check warning, but I don't see it when building with clang. In any case, the current and known future users of this helper require non-null args, so I'm converting the 'if' to an assert.
2019-10-29[IR] move helper function to replace undef constant (elements) with fixed ↵Sanjay Patel1-4/+25
constants This is the NFC part of D69519. We had this functionality locally in instcombine, but it can be used elsewhere, so hoisting it to Constant class.
2019-08-24[Constant] Add 'isElementWiseEqual()' methodRoman Lebedev1-0/+15
Promoting it from InstCombine's tryToReuseConstantFromSelectInComparison(). Return true if this constant and a constant 'Y' are element-wise equal. This is identical to just comparing the pointers, with the exception that for vectors, if only one of the constants has an `undef` element in some lane, the constants still match. llvm-svn: 369842
2019-08-22IR. Change strip* family of functions to not look through aliases.Peter Collingbourne1-4/+2
I noticed another instance of the issue where references to aliases were being replaced with aliasees, this time in InstCombine. In the instance that I saw it turned out to be only a QoI issue (a symbol ended up being missing from the symbol table due to the last reference to the alias being removed, preventing HWASAN from symbolizing a global reference), but it could easily have manifested as incorrect behaviour. Since this is the third such issue encountered (previously: D65118, D65314) it seems to be time to address this common error/QoI issue once and for all and make the strip* family of functions not look through aliases. Includes a test for the specific issue that I saw, but no doubt there are other similar bugs fixed here. As with D65118 this has been tested to make sure that the optimization isn't load bearing. I built Clang, Chromium for Linux, Android and Windows as well as the test-suite and there were no size regressions. Differential Revision: https://reviews.llvm.org/D66606 llvm-svn: 369697
2019-08-14[IR] Simplify removeDeadConstantUsers. NFCFangrui Song1-6/+3
llvm-svn: 368833
2019-07-18Fix typo in r366494. Spotted by Yuanfang Chen.Peter Collingbourne1-1/+1
llvm-svn: 366497
2019-07-18IR: Teach Constant::needsRelocation() that relative pointers don't need to ↵Peter Collingbourne1-11/+23
be relocated. This causes sections with relative pointers to be marked as read only, which means that they won't end up sharing pages with writable data. Differential Revision: https://reviews.llvm.org/D64948 llvm-svn: 366494
2019-05-05[Constants] Simplify type checking switch in ConstantExpr::get.Craig Topper1-26/+6
Summary: Remove duplicate checks that both operands have the same type. This is checked before the switch. Use 'integer' or 'floating-point' instead of 'arithmetic' type. I think this might be a leftover to the days when floating point and integer operations shared the same opcodes. Reviewers: spatel, RKSimon, dblaikie Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61558 llvm-svn: 359985
2019-05-05Add FNeg IR constant folding supportCameron McInally1-4/+6
llvm-svn: 359982
2019-04-07Change some StringRef::data() reinterpret_cast to bytes_begin() or ↵Fangrui Song1-1/+1
arrayRefFromStringRef() llvm-svn: 357852
2019-03-14[InstCombine] canonicalize funnel shift constant shift amount to be modulo ↵Sanjay Patel1-0/+10
bitwidth The shift argument is defined to be modulo the bitwidth, so if that argument is a constant, we can always reduce the constant to its minimal form to allow better CSE and other follow-on transforms. We need to be careful to ignore constant expressions here, or we will likely infinite loop. I'm adding a general vector constant query for that case. Differential Revision: https://reviews.llvm.org/D59374 llvm-svn: 356192
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
2019-01-10[opaque pointer types] Remove some calls to generic Type subtype accessors.James Y Knight1-3/+2
That is, remove many of the calls to Type::getNumContainedTypes(), Type::subtypes(), and Type::getContainedType(N). I'm not intending to remove these accessors -- they are useful/necessary in some cases. However, removing the pointee type from pointers would potentially break some uses, and reducing the number of calls makes it easier to audit. llvm-svn: 350835
2018-12-12[ConstantInt] Check active bits before calling getZExtValue.Florian Hahn1-1/+5
Without this check, we hit an assertion in getZExtValue, if the constant value does not fit into an uint64_t. As getZExtValue returns an uint64_t, should we update getAggregateElement to take an uin64_t as well? This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6109. Reviewers: efriedma, craig.topper, spatel Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D55547 llvm-svn: 348906
2018-12-10APFloat: allow 64-bit of payloadJF Bastien1-2/+24
Summary: The APFloat and Constant APIs taking an APInt allow arbitrary payloads, and that's great. There's a convenience API which takes an unsigned, and that's silly because it then directly creates a 64-bit APInt. Just change it to 64-bits directly. At the same time, add ConstantFP NaN getters which match the APFloat ones (with getQNaN / getSNaN and APInt parameters). Improve the APFloat testing to set more payload bits. Reviewers: scanon, rjmccall Subscribers: jkorous, dexonsmith, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D55460 llvm-svn: 348791
2018-12-01[InstCombine] Support ssub.sat canonicalization for non-splatsNikita Popov1-11/+8
Extend ssub.sat(X, C) -> sadd.sat(X, -C) canonicalization to also support non-splat vector constants. This is done by generalizing the implementation of the isNotMinSignedValue() helper to return true for constants that are non-splat, but don't contain any signed min elements. Differential Revision: https://reviews.llvm.org/D55011 llvm-svn: 348072
2018-11-17Use llvm::copy. NFCFangrui Song1-1/+1
llvm-svn: 347126
2018-11-13[IR] Add a dedicated FNeg IR InstructionCameron McInally1-0/+30
The IEEE-754 Standard makes it clear that fneg(x) and fsub(-0.0, x) are two different operations. The former is a bitwise operation, while the latter is an arithmetic operation. This patch creates a dedicated FNeg IR Instruction to model that behavior. Differential Revision: https://reviews.llvm.org/D53877 llvm-svn: 346774
generated by cgit v1.1 at 2025-10-16 11:36:33 +0000