aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/ConstantFolding.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-07-30[NFC] GetUnderlyingObject -> getUnderlyingObjectVitaly Buka1-1/+1
I am going to touch them in the next patch anyway
2020-07-29[ConstantFolding] fold integer min/max intrinsicsSanjay Patel1-0/+33
If both operands are undef, return undef. If one operand is undef, clamp to limit constant.
2020-07-26[ConstantFolding] Fold freeze if it is never undef or poisonJuneyoung Lee1-0/+2
This is a simple patch that adds constant folding for freeze instruction. IIUC, it isn't needed to update ConstantFold.cpp because there is no freeze constexpr. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D84597
2020-07-22[SVE] Remove calls to VectorType::getNumElements from AnalysisChristopher Tetreault1-5/+5
Reviewers: efriedma, fpetrogalli, c-rhodes, asbirlea, RKSimon Reviewed By: RKSimon Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81504
2020-07-21[ARM] Constant fold VCTP intrinsicsDavid Green1-1/+34
We can sometimes get into the situation where the operand to a vctp intrinsic becomes constant, such as after a loop is fully unrolled. This adds the constant folding needed for them, allowing them to simplify away and hopefully simplifying remaining instructions. Differential Revision: https://reviews.llvm.org/D84110
2020-07-19[ConstantFolding] check applicability of AllOnes constant creation firstJameson Nash1-2/+6
The getAllOnesValue can only handle things that are bitcast from a ConstantInt, while here we bitcast through a pointer, so we may see more complex objects (like Array or Struct). Differential Revision: https://reviews.llvm.org/D83870
2020-07-13[GVN] teach ConstantFolding correct handling of non-integral addrspace castsJameson Nash1-1/+11
Here we teach the ConstantFolding analysis pass that it is not legal to replace a load of a bitcast constant (having a non-integral addrspace) with a bitcast of the value of that constant (with a different non-integral addrspace). But also teach it that certain bit patterns are always known and convertable (a fact it already uses elsewhere). This required us to also fix a globalopt test, since, after this change, LLVM is able to realize that the test actually is a valid transform (NULL is always a known bit-pattern) and so it doesn't need to emit the failure remarks for it. Also simplify some of the negative tests for transforms by avoiding a type change in their bitcast, and add positive versions of the same tests, to show that they otherwise should work. Differential Revision: https://reviews.llvm.org/D59730
2020-07-13[GVN] add early exit to ConstantFoldLoadThroughBitcast [NFC]Jameson Nash1-1/+6
And adds some additional test coverage to ensure later commits don't introduce regressions. Differential Revision: https://reviews.llvm.org/D59730
2020-07-09ConstantFoldScalarCall3 - use const APInt& returned by getValue()Simon Pilgrim1-2/+2
Avoids unnecessary APInt copies and silences clang tidy warning.
2020-06-16[NFC] Bail out for scalable vectors before calling getNumElementsChristopher Tetreault1-8/+10
Summary: Move the bail out logic to before constructing the Result and Lane vectors. This is both potentially faster, and avoids calling getNumElements on a potentially scalable vector Reviewers: efriedma, sunfish, chandlerc, c-rhodes, fpetrogalli Reviewed By: fpetrogalli Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81619
2020-06-03[AMDGPU] Fold llvm.amdgcn.cos and llvm.amdgcn.sin intrinsics (fix)Jay Foad1-1/+4
Try to fix Windows buildbots.
2020-06-03[AMDGPU] Fold llvm.amdgcn.cos and llvm.amdgcn.sin intrinsicsJay Foad1-1/+20
Differential Revision: https://reviews.llvm.org/D80702
2020-05-29[ConstantFolding] Constant folding for integer vector reduce intrinsicsDavid Green1-0/+84
This add constant folding for all the integer vector reduce intrinsics, providing that the argument is a constant vector. zeroinitializer always produces 0 for all intrinsics, and other values can be handled with APInt operators. Differential Revision: https://reviews.llvm.org/D80516
2020-05-28[SVE] Eliminate calls to default-false VectorType::get() from AnalysisChristopher Tetreault1-6/+6
Reviewers: efriedma, fpetrogalli, kmclaughlin, sunfish Reviewed By: fpetrogalli Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80324
2020-05-26[FPEnv] Intrinsic llvm.roundevenSerge Pavlov1-0/+7
This intrinsic implements IEEE-754 operation roundToIntegralTiesToEven, and performs rounding to the nearest integer value, rounding halfway cases to even. The intrinsic represents the missed case of IEEE-754 rounding operations and now llvm provides full support of the rounding operations defined by the standard. Differential Revision: https://reviews.llvm.org/D75670
2020-05-22InstCombine: Add constant folding/simplify for amdgcn.ldexp intrinsicMatt Arsenault1-0/+11
This really belongs in InstructionSimplify since it doesn't introduce new instructions. Put it in instcombine to avoid increasing the number of passes considering target intrinsics. I also noticed that we seem to now be interpreting strictfp attributes on call sites, so try to handle that.
2020-04-23[SVE] Remove calls to VectorType::isScalable from analysisChristopher Tetreault1-4/+3
Reviewers: efriedma, sdesmalen, chandlerc, sunfish Reviewed By: efriedma Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77692
2020-04-09Clean up usages of asserting vector getters in TypeChristopher Tetreault1-8/+9
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: sunfish, sdesmalen, efriedma Reviewed By: efriedma Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77273
2020-04-09[KnownBits] Move AND, OR and XOR logic into KnownBitsJay Foad1-2/+1
Summary: There are at least three clients for KnownBits calculations: ValueTracking, SelectionDAG and GlobalISel. To reduce duplication the common logic should be moved out of these clients and into KnownBits itself. This patch does this for AND, OR and XOR calculations by implementing and using appropriate operator overloads KnownBits::operator& etc. Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74060
2020-04-09[FPEnv] Use single enum to represent rounding modeSerge Pavlov1-4/+2
Now compiler defines 5 sets of constants to represent rounding mode. These are: 1. `llvm::APFloatBase::roundingMode`. It specifies all 5 rounding modes defined by IEEE-754 and is used in `APFloat` implementation. 2. `clang::LangOptions::FPRoundingModeKind`. It specifies 4 of 5 IEEE-754 rounding modes and a special value for dynamic rounding mode. It is used in clang frontend. 3. `llvm::fp::RoundingMode`. Defines the same values as `clang::LangOptions::FPRoundingModeKind` but in different order. It is used to specify rounding mode in in IR and functions that operate IR. 4. Rounding mode representation used by `FLT_ROUNDS` (C11, 5.2.4.2.2p7). Besides constants for rounding mode it also uses a special value to indicate error. It is convenient to use in intrinsic functions, as it represents platform-independent representation for rounding mode. In this role it is used in some pending patches. 5. Values like `FE_DOWNWARD` and other, which specify rounding mode in library calls `fesetround` and `fegetround`. Often they represent bits of some control register, so they are target-dependent. The same names (not values) and a special name `FE_DYNAMIC` are used in `#pragma STDC FENV_ROUND`. The first 4 sets of constants are target independent and could have the same numerical representation. It would simplify conversion between the representations. Also now `clang::LangOptions::FPRoundingModeKind` and `llvm::fp::RoundingMode` do not contain the value for IEEE-754 rounding direction `roundTiesToAway`, although it is supported natively on some targets. This change defines all the rounding mode type via one `llvm::RoundingMode`, which also contains rounding mode for IEEE rounding direction `roundTiesToAway`. Differential Revision: https://reviews.llvm.org/D77379
2020-04-06Remove SequentialType from the type heirarchy.Eli Friedman1-10/+13
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-1/+2
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-28[FEnv] Constfold some unary constrained operationsSerge Pavlov1-29/+100
This change implements constant folding to constrained versions of intrinsics, implementing rounding: floor, ceil, trunc, round, rint and nearbyint. Differential Revision: https://reviews.llvm.org/D72930
2020-03-27[llvm][Support] Add isZero method for TypeSize. [NFC]Francesco Petrogalli1-1/+1
Summary: The method is used where TypeSize is implicitly cast to integer for being checked against 0. Reviewers: sdesmalen, efriedma Reviewed By: sdesmalen, efriedma Subscribers: efriedma, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76748
2020-03-06[AMDGPU][ConstantFolding] Fold llvm.amdgcn.cube* intrinsicsJay Foad1-0/+68
Summary: This folds the following family of intrinsics: llvm.amdgcn.cubeid (face id) llvm.amdgcn.cubema (major axis) llvm.amdgcn.cubesc (S coordinate) llvm.amdgcn.cubetc (T coordinate) Reviewers: nhaehnle, arsenm, rampitec Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75187
2020-03-06[APFloat] Make use of new overloaded comparison operators. NFC.Jay Foad1-16/+8
Reviewers: ekatz, spatel, jfb, tlively, craig.topper, RKSimon, nikic, scanon Subscribers: arsenm, jvesely, nhaehnle, hiraditya, dexonsmith, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75744
2020-03-04[ConstantFolding] Always return something from ConstantFoldConstantNikita Popov1-24/+12
Spin-off from D75407. As described there, ConstantFoldConstant() currently returns null for non-ConstantExpr/ConstantVector inputs, but otherwise always returns non-null, independently of whether any folding has happened or not. This is confusing and makes consumer code more complicated. I would expect either that ConstantFoldConstant() returns only if it actually folded something, or that it always returns non-null. I'm going to the latter possibility here, which appears to be more useful considering existing usage. Differential Revision: https://reviews.llvm.org/D75543
2020-02-27[AMDGPU][ConstantFolding] Fold llvm.amdgcn.fract intrinsicJay Foad1-1/+15
Reviewers: nhaehnle, arsenm, rampitec Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75179
2020-02-19[AMDGPU][ConstantFolding] Fold llvm.amdgcn.fmul.legacy intrinsicJay Foad1-0/+12
Reviewers: arsenm, rampitec, nhaehnle Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74835
2020-02-17Reapply "[IRBuilder] Virtualize IRBuilder"Nikita Popov1-0/+3
Relative to the original commit, this fixes some warnings, and is based on the deletion of the IRBuilder copy constructor in D74693. The automatic copy constructor would no longer be safe. ----- Related llvm-dev thread: http://lists.llvm.org/pipermail/llvm-dev/2020-February/138951.html This patch moves the IRBuilder from templating over the constant folder and inserter towards making both of these virtual. There are a couple of motivations for this: 1. It's not possible to share code between use-sites that use different IRBuilder folders/inserters (short of templating the code and moving it into headers). 2. Methods currently defined on IRBuilderBase (which is not templated) do not use the custom inserter, resulting in subtle bugs (e.g. incorrect InstCombine worklist management). It would be possible to move those into the templated IRBuilder, but... 3. The vast majority of the IRBuilder implementation has to live in the header, because it depends on the template arguments. 4. We have many unnecessary dependencies on IRBuilder.h, because it is not easy to forward-declare. (Significant parts of the backend depend on it via TargetLowering.h, for example.) This patch addresses the issue by making the following changes: * IRBuilderDefaultInserter::InsertHelper becomes virtual. IRBuilderBase accepts a reference to it. * IRBuilderFolder is introduced as a virtual base class. It is implemented by ConstantFolder (default), NoFolder and TargetFolder. IRBuilderBase has a reference to this as well. * All the logic is moved from IRBuilder to IRBuilderBase. This means that methods can in the future replace their IRBuilder<> & uses (or other specific IRBuilder types) with IRBuilderBase & and thus be usable with different IRBuilders. * The IRBuilder class is now a thin wrapper around IRBuilderBase. Essentially it only stores the folder and inserter and takes care of constructing the base builder. What this patch doesn't do, but should be simple followups after this change: * Fixing use of the inserter for creation methods originally defined on IRBuilderBase. * Replacing IRBuilder<> uses in arguments with IRBuilderBase, where useful. * Moving code from the IRBuilder header to the source file. From the user perspective, these changes should be mostly transparent: The only thing that consumers using a custom inserted may need to do is inherit from IRBuilderDefaultInserter publicly and mark their InsertHelper as public. Differential Revision: https://reviews.llvm.org/D73835
2020-02-16Revert "[IRBuilder] Virtualize IRBuilder"Nikita Popov1-3/+0
This reverts commit 0765d3824d069f37596bc5a890399099b776c2a0. This reverts commit 1b04866a3db9f816a559860f941da067fe1eccf1. Relevant looking crashes observed on: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win
2020-02-16[IRBuilder] Virtualize IRBuilderNikita Popov1-0/+3
Related llvm-dev thread: http://lists.llvm.org/pipermail/llvm-dev/2020-February/138951.html This patch moves the IRBuilder from templating over the constant folder and inserter towards making both of these virtual. There are a couple of motivations for this: 1. It's not possible to share code between use-sites that use different IRBuilder folders/inserters (short of templating the code and moving it into headers). 2. Methods currently defined on IRBuilderBase (which is not templated) do not use the custom inserter, resulting in subtle bugs (e.g. incorrect InstCombine worklist management). It would be possible to move those into the templated IRBuilder, but... 3. The vast majority of the IRBuilder implementation has to live in the header, because it depends on the template arguments. 4. We have many unnecessary dependencies on IRBuilder.h, because it is not easy to forward-declare. (Significant parts of the backend depend on it via TargetLowering.h, for example.) This patch addresses the issue by making the following changes: * IRBuilderDefaultInserter::InsertHelper becomes virtual. IRBuilderBase accepts a reference to it. * IRBuilderFolder is introduced as a virtual base class. It is implemented by ConstantFolder (default), NoFolder and TargetFolder. IRBuilderBase has a reference to this as well. * All the logic is moved from IRBuilder to IRBuilderBase. This means that methods can in the future replace their IRBuilder<> & uses (or other specific IRBuilder types) with IRBuilderBase & and thus be usable with different IRBuilders. * The IRBuilder class is now a thin wrapper around IRBuilderBase. Essentially it only stores the folder and inserter and takes care of constructing the base builder. What this patch doesn't do, but should be simple followups after this change: * Fixing use of the inserter for creation methods originally defined on IRBuilderBase. * Replacing IRBuilder<> uses in arguments with IRBuilderBase, where useful. * Moving code from the IRBuilder header to the source file. From the user perspective, these changes should be mostly transparent: The only thing that consumers using a custom inserted may need to do is inherit from IRBuilderDefaultInserter publicly and mark their InsertHelper as public. Differential Revision: https://reviews.llvm.org/D73835
2020-02-12[ConstantFold][SVE] Fix constant fold for FoldReinterpretLoadFromConstPtr.Huihui Zhang1-3/+8
Summary: Bail out early for scalable vectors. As global variables are not expected to be scalable. Use explicit call of getFixedSize() to assert on places where scalable size doesn't make sense. Reviewers: sdesmalen, efriedma, apazos, huntergr, willlovett Reviewed By: sdesmalen Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74424
2020-02-12[ConstantFolding] Fold calls to FP remainder functionEhud Katz1-1/+13
With the fixed implementation of the "remainder" operation in rG9d0956ebd471, we can now add support to folding calls to it. Differential Revision: https://reviews.llvm.org/D69777
2020-02-11[ConstantFold][SVE] Fix constand fold for vector call.Huihui Zhang1-0/+5
Summary: Do not iterate on scalable vectors. Reviewers: sdesmalen, efriedma, apazos, huntergr, willlovett Reviewed By: sdesmalen Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74419
2020-01-22Add support for (expressing) vscale.Sander de Smalen1-1/+2
In LLVM IR, vscale can be represented with an intrinsic. For some targets, this is equivalent to the constexpr: getelementptr <vscale x 1 x i8>, <vscale x 1 x i8>* null, i32 1 This can be used to propagate the value in CodeGenPrepare. In ISel we add a node that can be legalized to one or more instructions to materialize the runtime vector length. This patch also adds SVE CodeGen support for VSCALE, which maps this node to RDVL instructions (for scaled multiples of 16bytes) or CNT[HSD] instructions (scaled multiples of 2, 4, or 8 bytes, respectively). Reviewers: rengolin, cameron.mcinally, hfinkel, sebpop, SjoerdMeijer, efriedma, lattner Reviewed by: efriedma Tags: #llvm Differential Revision: https://reviews.llvm.org/D68203
2019-12-13Reland [DataLayout] Fix occurrences that size and range of pointers are ↵Nicola Zaghen1-10/+10
assumed to be the same. GEP index size can be specified in the DataLayout, introduced in D42123. However, there were still places in which getIndexSizeInBits was used interchangeably with getPointerSizeInBits. This notably caused issues with Instcombine's visitPtrToInt; but the unit tests was incorrect, so this remained undiscovered. This fixes the buildbot failures. Differential Revision: https://reviews.llvm.org/D68328 Patch by Joseph Faulls!
2019-12-12Temporarily Revert "[DataLayout] Fix occurrences that size and range of ↵Nicola Zaghen1-10/+10
pointers are assumed to be the same." This reverts commit 5f6208778ff92567c57d7c1e2e740c284d7e69a5. This caused failures in Transforms/PhaseOrdering/scev-custom-dl.ll const: Assertion `getBitWidth() == CR.getBitWidth() && "ConstantRange types don't agree!"' failed.
2019-12-12[DataLayout] Fix occurrences that size and range of pointers are assumed to ↵Nicola Zaghen1-10/+10
be the same. GEP index size can be specified in the DataLayout, introduced in D42123. However, there were still places in which getIndexSizeInBits was used interchangeably with getPointerSizeInBits. This notably caused issues with Instcombine's visitPtrToInt; but the unit tests was incorrect, so this remained undiscovered. Differential Revision: https://reviews.llvm.org/D68328 Patch by Joseph Faulls!
2019-12-11[IR] Split out target specific intrinsic enums into separate headersReid Kleckner1-0/+2
This has two main effects: - Optimizes debug info size by saving 221.86 MB of obj file size in a Windows optimized+debug build of 'all'. This is 3.03% of 7,332.7MB of object file size. - Incremental step towards decoupling target intrinsics. The enums are still compact, so adding and removing a single target-specific intrinsic will trigger a rebuild of all of LLVM. Assigning distinct target id spaces is potential future work. Part of PR34259 Reviewers: efriedma, echristo, MaskRay Reviewed By: echristo, MaskRay Differential Revision: https://reviews.llvm.org/D71320
2019-09-30[ConstantFolding] Fold constant calls to log2()Evandro Menezes1-0/+9
Somehow, folding calls to `log2()` with a constant was missing. Differential revision: https://reviews.llvm.org/D67300 llvm-svn: 373262
2019-09-26ConstantFold - silence static analyzer dyn_cast<ExtractValueInst> null ↵Simon Pilgrim1-1/+1
dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<ExtractValueInst> directly and if not assert will fire for us. llvm-svn: 372993
2019-09-26[ConstantFolding] Use FoldBitCast correctlyKeno Fischer1-2/+20
Previously we might attempt to use a BitCast to turn bits into vectors of pointers, but that requires an inttoptr cast to be legal. Add an assertion to detect the formation of illegal bitcast attempts early (in the tests, we often constant-fold away the result before getting to this assertion check), while being careful to still handle the early-return conditions without adding extra complexity in the result. Patch by Jameson Nash <jameson@juliacomputing.com>. Differential Revision: https://reviews.llvm.org/D65057 llvm-svn: 372940
2019-09-12[ConstantFolding] Expand folding of some library functionsEvandro Menezes1-3/+22
Expanding the folding of `nearbyint()`, `rint()` and `trunc()` to library functions, in addition to the current support for intrinsics. Differential revision: https://reviews.llvm.org/D67468 llvm-svn: 371774
2019-09-12[ConstProp] allow folding for fma that produces NaNSanjay Patel1-7/+3
Folding for fma/fmuladd was added here: rL202914 ...and as seen in existing/unchanged tests, that works to propagate NaN if it's already an input, but we should fold an fma() that creates NaN too. From IEEE-754-2008 7.2 "Invalid Operation", there are 2 clauses that apply to fma, so I added tests for those patterns: c) fusedMultiplyAdd: fusedMultiplyAdd(0, ∞, c) or fusedMultiplyAdd(∞, 0, c) unless c is a quiet NaN; if c is a quiet NaN then it is implementation defined whether the invalid operation exception is signaled d) addition or subtraction or fusedMultiplyAdd: magnitude subtraction of infinities, such as: addition(+∞, −∞) Differential Revision: https://reviews.llvm.org/D67446 llvm-svn: 371735
2019-09-11[ConstantFolding] Refactor math functions to use LLVM ones (NFC)Evandro Menezes1-37/+42
When possible, replace calls to library routines on the host with equivalent ones in LLVM. Differential revision: https://reviews.llvm.org/D67459 llvm-svn: 371677
2019-09-06[ConstantFolding] Refactor functions not available before C99 (NFC)Evandro Menezes1-1/+6
Note the cases when calling a function at compile time may fail if the host does not support the C99 run time library. llvm-svn: 371236
2019-09-06[ConstantFolding] Refactor function match for better speed (NFC)Evandro Menezes1-102/+134
Use an `enum` instead of string comparison to match the candidate function. llvm-svn: 371228
2019-09-01[ConstantFolding] Fix 'undef' folding for @llvm.[us]{add,sub}.with.overflow ↵Roman Lebedev1-11/+18
ops (PR43188) As we have already established/fixed in https://bugs.llvm.org/show_bug.cgi?id=42209 https://reviews.llvm.org/D63065 https://reviews.llvm.org/rL363522 the InstSimplify handling for @llvm.with.overflow ops with undefs is correct. Therefore if ConstantFolding produces different results, then it is wrong. This duplication of code hints at the need for some refactoring, but for now address the brokenness of ConstantFolding by copying the known-good handling from rL363522. Fixes https://bugs.llvm.org/show_bug.cgi?id=43188 llvm-svn: 370608
2019-08-22IR. Change strip* family of functions to not look through aliases.Peter Collingbourne1-2/+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
generated by cgit v1.1 at 2025-09-30 07:40:10 +0000