aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/ConstantFolding.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-07-31[SCCP] Update condition to avoid overflow.Alina Sbirlea1-1/+1
Summary: Update condition to remove addition that may cause an overflow. Resolves PR42814. Reviewers: sanjoy, RKSimon Subscribers: jlebar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65417 llvm-svn: 367461
2019-07-22Analysis: Don't look through aliases when simplifying GEPs.Peter Collingbourne1-1/+1
It is not safe in general to replace an alias in a GEP with its aliasee if the alias can be replaced with another definition (i.e. via strong/weak resolution (linkonce_odr) or via symbol interposition (default visibility in ELF)) while the aliasee cannot. An example of how this can go wrong is in the included test case. I was concerned that this might be a load-bearing misoptimization (it's possible for us to use aliases to share vtables between base and derived classes, and on Windows, vtable symbols will always be aliases in RTTI mode, so this change could theoretically inhibit trivial devirtualization in some cases), so I built Chromium for Linux and Windows with and without this change. The file sizes of the resulting binaries were identical, so it doesn't look like this is going to be a problem. Differential Revision: https://reviews.llvm.org/D65118 llvm-svn: 366754
2019-07-11[SCEV] teach SCEV symbolical execution about overflow intrinsics folding.Chen Zheng1-0/+3
Differential Revision: https://reviews.llvm.org/D64422 llvm-svn: 365726
2019-06-24[ConstantFolding] Use hasVectorInstrinsicScalarOpd. NFCBjorn Pettersson1-16/+13
Summary: Use the hasVectorInstrinsicScalarOpd helper function in ConstantFoldVectorCall. Reviewers: rengolin, RKSimon, dblaikie Reviewed By: rengolin, RKSimon Subscribers: tschuett, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63705 llvm-svn: 364178
2019-06-19[ConstantFolding] Add constant folding for smul.fix and smul.fix.satBjorn Pettersson1-0/+46
Summary: This patch teaches ConstantFolding to constant fold both scalar and vector variants of llvm.smul.fix and llvm.smul.fix.sat. As described in the LangRef rounding is unspecified for these instrinsics. If the result cannot be represented exactly the default behavior in ConstantFolding is to round down towards negative infinity. If a target has a preferred rounding that is different some kind of target hook would be needed (same strategy as used by the SelectionDAG legalizer). Reviewers: nikic, leonardchan, RKSimon Reviewed By: leonardchan Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63385 llvm-svn: 363811
2019-06-19[ConstantFolding] Refactor ConstantFoldScalarCall. NFCBjorn Pettersson1-469/+497
This patch splits ConstantFoldScalarCall into several functions. Benefits: - Reduces indentation levels and avoids long if-statements. - Makes it easier to add support for > 3 operands. llvm-svn: 363810
2019-06-19[ConstantFolding] Fix assertion failure on non-power-of-two vector load.Jay Foad1-1/+1
Summary: The test case does an (out of bounds) load from a global constant with type <3 x float>. InstSimplify tried to turn this into an integer load of the whole alloc size of the vector, which is 128 bits due to alignment padding, and then bitcast this to <3 x vector> which failed an assertion due to the type size mismatch. The fix is to do an integer load of the normal size of the vector, with no alignment padding. Reviewers: tpr, arsenm, majnemer, dstuttard Reviewed By: arsenm Subscribers: hfinkel, wdng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63375 llvm-svn: 363784
2019-06-07[NFC] Don't export helpers of ConstantFoldCallJoerg Sonnenberger1-9/+11
llvm-svn: 362799
2019-05-05Add FNeg IR constant folding supportCameron McInally1-1/+10
llvm-svn: 359982
2019-03-22[ConstantFolding] Fix GetConstantFoldFPValue to avoid cast overflow.Bixia Zheng1-4/+2
Summary: In C++, the behavior of casting a double value that is beyond the range of a single precision floating-point to a float value is undefined. This change replaces such a cast with APFloat::convert to convert the value, which is consistent with how we convert a double value to a half value. Reviewers: sanjoy Subscribers: lebedev.ri, sanjoy, jlebar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59500 llvm-svn: 356781
2019-02-11[CallSite removal] Migrate ConstantFolding APIs and implementation toChandler Carruth1-26/+29
`CallBase`. Users have been updated. You can see how to update any out-of-tree usages: pass `cast<CallBase>(CS.getInstruction())`. llvm-svn: 353661
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-11[ConstantFolding] Fold undef for integer intrinsicsNikita Popov1-63/+114
This fixes https://bugs.llvm.org/show_bug.cgi?id=40110. This implements handling of undef operands for integer intrinsics in ConstantFolding, in particular for the bitcounting intrinsics (ctpop, cttz, ctlz), the with.overflow intrinsics, the saturating math intrinsics and the funnel shift intrinsics. The undef behavior follows what InstSimplify does for the general cas e of non-constant operands. For the bitcount intrinsics (where InstSimplify doesn't do undef handling -- there cannot be a combination of an undef + non-constant operand) I'm using a 0 result if the intrinsic is defined for zero and undef otherwise. Differential Revision: https://reviews.llvm.org/D55950 llvm-svn: 350971
2018-12-11[ConstantFolding] Handle leading zero-size elements in load foldingNikita Popov1-2/+13
Struct types may have leading zero-size elements like [0 x i32], in which case the "real" element at offset 0 will not necessarily coincide with the 0th element of the aggregate. ConstantFoldLoadThroughBitcast() wants to drill down the element at offset 0, but currently always picks the 0th aggregate element to do so. This patch changes the code to find the first non-zero-size element instead, for the struct case. The motivation behind this change is https://github.com/rust-lang/rust/issues/48627. Rust is fond of emitting [0 x iN] separators between struct elements to enforce alignment, which prevents constant folding in this particular case. The additional tests with [4294967295 x [0 x i32]] check that we don't end up unnecessarily looping over a large number of zero-size elements of a zero-size array. Differential Revision: https://reviews.llvm.org/D55169 llvm-svn: 348895
2018-11-20[ConstantFolding] Add support for saturating add/subSanjay Patel1-0/+12
Support saturating add/sub in constant folding, based on the APInt methods introduced in D54332. Patch by: @nikic (Nikita Popov) Differential Revision: https://reviews.llvm.org/D54531 llvm-svn: 347328
2018-11-07Add support for llvm.is.constant intrinsic (PR4898)James Y Knight1-0/+22
This adds the llvm-side support for post-inlining evaluation of the __builtin_constant_p GCC intrinsic. Also fixed SCCPSolver::visitCallSite to not blow up when seeing a call to a function where canConstantFoldTo returns true, and one of the arguments is a struct. Updated from patch initially by Janusz Sobczak. Differential Revision: https://reviews.llvm.org/D4276 llvm-svn: 346322
2018-10-19[ConstantFolding] Constant fold minimum and maximum intrinsicsThomas Lively1-0/+14
Summary: Depends on D52764 Reviewers: aheejin, dschuff Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52765 llvm-svn: 344796
2018-09-11Prevent Constant Folding From Optimizing inrange GEPPeter Collingbourne1-9/+2
This patch does the following things: 1. update SymbolicallyEvaluateGEP so that it bails out if it cannot preserve inrange arribute; 2. update llvm/test/Analysis/ConstantFolding/gep.ll to remove UB in it; 3. remove inaccurate comment above ConstantFoldInstOperandsImpl in llvm/lib/Analysis/ConstantFolding.cpp; 4. add a new regression test that makes sure that no optimizations change an inrange GEP in an unexpected way. Patch by Zhaomo Yang! Differential Revision: https://reviews.llvm.org/D51698 llvm-svn: 341888
2018-08-17[ConstantFolding] add simplifications for funnel shift intrinsicsSanjay Patel1-0/+25
This is another step towards being able to canonicalize to the funnel shift intrinsics in IR (see D49242 for the initial patch). We should not have any loss of simplification power in IR between these and the equivalent IR constructs. Differential Revision: https://reviews.llvm.org/D50848 llvm-svn: 340022
2018-08-12[X86] Add constant folding for AVX512 versions of scalar floating point to ↵Craig Topper1-5/+76
integer conversion intrinsics. Summary: We've supported constant folding for sse versions for many years. This patch adds support for the avx512 versions including unsigned with the default rounding mode. We could probably do more with other roundings modes and SAE in the future. The test cases are largely based on the sse.ll test cases. But I did add some test cases to ensure the unsigned versions don't accept negative values. Also checked the bounds of f64->i32 conversions to make sure unsigned has a larger positive range than signed. Reviewers: RKSimon, spatel, chandlerc Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50553 llvm-svn: 339529
2018-07-23ConstantFolding: Avoid a crash.Manoj Gupta1-6/+13
Summary: Check if the parent basic block and caller exists before calling CS.getCaller when constant folding strip.invariant.group instrinsic. This avoids a crash when the function containing the intrinsic is being inlined. The instruction is checked for any simplifiction but has not yet been added to a basic block. Reviewers: Prazek, rsmith, efriedma Reviewed By: efriedma Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D49690 llvm-svn: 337742
2018-07-09llvm: Add support for "-fno-delete-null-pointer-checks"Manoj Gupta1-6/+9
Summary: Support for this option is needed for building Linux kernel. This is a very frequently requested feature by kernel developers. More details : https://lkml.org/lkml/2018/4/4/601 GCC option description for -fdelete-null-pointer-checks: This Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. -fno-delete-null-pointer-checks is the inverse of this implying that null pointer dereferencing is not undefined. This feature is implemented in LLVM IR in this CL as the function attribute "null-pointer-is-valid"="true" in IR (Under review at D47894). The CL updates several passes that assumed null pointer dereferencing is undefined to not optimize when the "null-pointer-is-valid"="true" attribute is present. Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv Reviewed By: efriedma, george.burgess.iv Subscribers: eraman, haicheng, george.burgess.iv, drinkcat, theraven, reames, sanjoy, xbolva00, llvm-commits Differential Revision: https://reviews.llvm.org/D47895 llvm-svn: 336613
2018-07-02Implement strip.invariant.groupPiotr Padlewski1-3/+6
Summary: This patch introduce new intrinsic - strip.invariant.group that was described in the RFC: Devirtualization v2 Reviewers: rsmith, hfinkel, nlopes, sanjoy, amharc, kuhar Subscribers: arsenm, nhaehnle, JDevlieghere, hiraditya, xbolva00, llvm-commits Differential Revision: https://reviews.llvm.org/D47103 Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com> llvm-svn: 336073
2018-05-18Constant fold launder of null and undefPiotr Padlewski1-1/+12
Summary: This might be useful because clang will add some barriers for pointer comparisons. Reviewers: majnemer, dberlin, hfinkel, nlewycky, davide, rsmith, amharc, kuhar Subscribers: davide, amharc, llvm-commits Differential Revision: https://reviews.llvm.org/D32423 llvm-svn: 332786
2018-03-13[Evaluator] Evaluate load/store with bitcastEugene Leviant1-34/+39
Differential revision: https://reviews.llvm.org/D43457 llvm-svn: 327381
2018-02-14Adding a width of the GEP index to the Data Layout.Elena Demikhovsky1-20/+20
Making a width of GEP Index, which is used for address calculation, to be one of the pointer properties in the Data Layout. p[address space]:size:memory_size:alignment:pref_alignment:index_size_in_bits. The index size parameter is optional, if not specified, it is equal to the pointer size. Till now, the InstCombiner normalized GEPs and extended the Index operand to the pointer width. It works fine if you can convert pointer to integer for address calculation and all registered targets do this. But some ISAs have very restricted instruction set for the pointer calculation. During discussions were desided to retrieve information for GEP index from the Data Layout. http://lists.llvm.org/pipermail/llvm-dev/2018-January/120416.html I added an interface to the Data Layout and I changed the InstCombiner and some other passes to take the Index width into account. This change does not affect any in-tree target. I added tests to cover data layouts with explicitly specified index size. Differential Revision: https://reviews.llvm.org/D42123 llvm-svn: 325102
2017-10-01Revert "Fix typo [NFC]"Xin Tong1-6/+3
This reverts commit e60b5028619be1c81bd039d63a0627dac32d38f9. Incorrectly include changes that are not typo fix. llvm-svn: 314614
2017-10-01Fix typo [NFC]Xin Tong1-3/+6
llvm-svn: 314613
2017-08-14Add strictfp attribute to prevent unwanted optimizations of libm callsAndrew Kaylor1-3/+3
Differential Revision: https://reviews.llvm.org/D34163 llvm-svn: 310885
2017-06-09[InstSimplify] Don't constant fold or DCE calls that are marked nobuiltinAndrew Kaylor1-5/+14
Differential Revision: https://reviews.llvm.org/D33737 llvm-svn: 305132
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth1-1/+1
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-04[ConstantFolding] Combine an if statement into an earlier one that checked ↵Craig Topper1-7/+3
the same condition. NFC llvm-svn: 304681
2017-06-04[ConstantFolding][X86] Replace an LLVM_FALLTHROUGH with a break because it ↵Craig Topper1-1/+2
really shouldn't fallthrough. This is actually NFC because the next case starts with the same if statement as this case did. So the result will be the same and it will fallthrough to the end of the switch. But there's no reason to rely on that so we should just break. llvm-svn: 304680
2017-06-04[ConstantFolding] Properly support constant folding of vector powi ↵Craig Topper1-1/+2
intrinsic. The second argument is not a vector so needs special treatment. llvm-svn: 304679
2017-06-03[ConstantFolding] Fix constant folding for vector cttz and ctlz intrinsics ↵Craig Topper1-0/+7
to understand that the second argument is still a scalar. llvm-svn: 304668
2017-06-02[InstSimplify][ConstantFolding] Teach constant folding how to handle icmp ↵Craig Topper1-0/+7
null, (inttoptr x) as well as it handles icmp (inttoptr x), null Summary: The constant folding code currently assumes that the constant expression will always be on the left and the simple null will be on the right. But that's not true at least on the path from InstSimplify. This patch adds support to ConstantFolding to detect the reversed case. Reviewers: spatel, dberlin, majnemer, davide, joey Reviewed By: joey Subscribers: joey, llvm-commits Differential Revision: https://reviews.llvm.org/D33801 llvm-svn: 304559
2017-05-31Added missing break; added LLVM_FALLTHROUGH to address warning: this ↵Galina Kistanova1-0/+2
statement may fall through. NFC. llvm-svn: 304340
2017-05-24[ValueTracking] Convert most of the calls to computeKnownBits to use the ↵Craig Topper1-5/+2
version that returns the KnownBits object. This continues the changes started when computeSignBit was replaced with this new version of computeKnowBits. Differential Revision: https://reviews.llvm.org/D33431 llvm-svn: 303773
2017-05-12[ConstantFolding] Add folding for various math '__<func>_finite' routines ↵Andrew Kaylor1-11/+69
generated from -ffast-math Patch by Chris Chrulski Differential Revision: https://reviews.llvm.org/D31788 llvm-svn: 302956
2017-05-03[KnownBits] Add methods for determining if KnownBits is a constant valueCraig Topper1-5/+4
This patch adds isConstant and getConstant for determining if KnownBits represents a constant value and to retrieve the value. Use them to simplify code. Differential Revision: https://reviews.llvm.org/D32785 llvm-svn: 302091
2017-04-26[ValueTracking] Introduce a KnownBits struct to wrap the two APInts for ↵Craig Topper1-8/+9
computeKnownBits This patch introduces a new KnownBits struct that wraps the two APInt used by computeKnownBits. This allows us to treat them as more of a unit. Initially I've just altered the signatures of computeKnownBits and InstCombine's simplifyDemandedBits to pass a KnownBits reference instead of two separate APInt references. I'll do similar to the SelectionDAG version of computeKnownBits/simplifyDemandedBits as a separate patch. I've added a constructor that allows initializing both APInts to the same bit width with a starting value of 0. This reduces the repeated pattern of initializing both APInts. Once place default constructed the APInts so I added a default constructor for those cases. Going forward I would like to add more methods that will work on the pairs. For example trunc, zext, and sext occur on both APInts together in several places. We should probably add a clear method that can be used to clear both pieces. Maybe a method to check for conflicting information. A method to return (Zero|One) so we don't write it out everywhere. Maybe a method for (Zero|One).isAllOnesValue() to determine if all bits are known. I'm sure there are many other methods we can come up with. Differential Revision: https://reviews.llvm.org/D32376 llvm-svn: 301432
2017-04-07[ConstantFolding] Use Intrinsic::not_intrinsic instead of 0 for readability. ↵Craig Topper1-1/+1
NFCI llvm-svn: 299801
2017-03-21[ConstantFolding] Fix to prevent constant folding having to repeatedly scan ↵David Green1-1/+1
operands. NFCI After the loop unroll threshold was increased in r295538, very large constant expressions can be created. This prevents them from having to be recursively scanned, leading to a compile time blow-up. Differential Revision: https://reviews.llvm.org/D30689 llvm-svn: 298356
2017-03-20Use MutableArrayRef for APFloat::convertToIntegerSimon Pilgrim1-3/+3
As discussed on D31074, use MutableArrayRef for destination integer buffers to help assert before stack overflows happen. llvm-svn: 298253
2017-03-19[Analysis] bitreverse(undef) returns undefBrian Gesiak1-1/+2
Summary: The reverse of an artbitrary bitpattern is also an arbitrary bitpattern. Reviewers: trentxintong, arsenm, majnemer Reviewed By: majnemer Subscribers: majnemer, wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D31118 llvm-svn: 298201
2017-01-23[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)David L. Jones1-88/+88
Summary: The LibFunc::Func enum holds enumerators named for libc functions. Unfortunately, there are real situations, including libc implementations, where function names are actually macros (musl uses "#define fopen64 fopen", for example; any other transitively visible macro would have similar effects). Strictly speaking, a conforming C++ Standard Library should provide any such macros as functions instead (via <cstdio>). However, there are some "library" functions which are not part of the standard, and thus not subject to this rule (fopen64, for example). So, in order to be both portable and consistent, the enum should not use the bare function names. The old enum naming used a namespace LibFunc and an enum Func, with bare enumerators. This patch changes LibFunc to be an enum with enumerators prefixed with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override macros.) There are additional changes required in clang. Reviewers: rsmith Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D28476 llvm-svn: 292848
2017-01-21[ConstantFolding] Constant-fold llvm.sqrt(x) like other intrinsics.Justin Lebar1-13/+2
Summary: Currently we return undef, but we're in the process of changing the LangRef so that llvm.sqrt behaves like the other math intrinsics, matching the return value of the standard libcall but not setting errno. This change is legal even without the LangRef change because currently calling llvm.sqrt(x) where x is negative is spec'ed to be UB. But in practice it's also safe because we're simply constant-folding fewer inputs: Inputs >= -0 get constant-folded as before, but inputs < -0 now aren't constant-folded, because ConstantFoldFP aborts if the host math function raises an fp exception. Reviewers: hfinkel, efriedma, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28929 llvm-svn: 292692
2016-12-26[InstCombiner] Simplify lib calls to `round{,f}`Bryant Wong1-0/+6
Differential Revision: https://reviews.llvm.org/D28110 llvm-svn: 290542
2016-12-21[ConstantFolding] Fix vector GEPs harderMichael Kuperstein1-3/+6
For vector GEPs, CastGEPIndices can end up in an infinite recursion, because we compare the vector type to the scalar pointer type, find them different, and then try to cast a type to itself. Differential Revision: https://reviews.llvm.org/D28009 llvm-svn: 290260
2016-12-14Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann1-4/+4
At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
generated by cgit v1.1 at 2025-09-30 15:11:05 +0000