summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] Reorder pow() transformations (NFC)Evandro Menezes2019-07-121-23/+19
| | | | | | | Move the transformation from `powf(x, itofp(y))` to `powi(x, y)` to the group of transformations related to the exponent. llvm-svn: 365851
* [InstCombine] Reorder recently added/improved pow transformationsDavid Bolvansky2019-07-111-3/+3
| | | | | | Changed cases are now faster with exp2. llvm-svn: 365758
* [InstCombine] pow(C,x) -> exp2(log2(C)*x)David Bolvansky2019-07-101-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Transform pow(C,x) To exp2(log2(C)*x) if C > 0, C != inf, C != NaN (and C is not power of 2, since we have some fold for such case already). log(C) is folded by the compiler and exp2 is much faster to compute than pow. Reviewers: spatel, efriedma, evandro Reviewed By: evandro Subscribers: lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64099 llvm-svn: 365637
* [NFC] Strenghten isInteger condition for rL364940David Bolvansky2019-07-021-2/+3
| | | | llvm-svn: 364969
* [SimplifyLibCalls] powf(x, sitofp(n)) -> powi(x, n)David Bolvansky2019-07-021-12/+47
| | | | | | | | | | | | | | | | | | | Summary: Partially solves https://bugs.llvm.org/show_bug.cgi?id=42190 Reviewers: spatel, nikic, efriedma Reviewed By: efriedma Subscribers: efriedma, nikic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63038 llvm-svn: 364940
* [InstCombine] canonicalize fmin/fmax to LLVM intrinsics minnum/maxnumSanjay Patel2019-06-291-24/+14
| | | | | | | | | | | | | | This transform came up in D62414, but we should deal with it first. We have LLVM intrinsics that correspond exactly to libm calls (unlike most libm calls, these libm calls never set errno). This holds without any fast-math-flags, so we should always canonicalize to those intrinsics directly for better optimization. Currently, we convert to fcmp+select only when we have FMF (nnan) because fcmp+select does not preserve the semantics of the call in the general case. Differential Revision: https://reviews.llvm.org/D63214 llvm-svn: 364714
* [SimplifyLibCalls] Fold more fortified functions into non-fortified variantsErik Pilkington2019-05-311-15/+132
| | | | | | | | | | | | When the object size argument is -1, no checking can be done, so calling the _chk variant is unnecessary. We already did this for a bunch of these functions. rdar://50797197 Differential revision: https://reviews.llvm.org/D62358 llvm-svn: 362272
* NFC: Pull out a function to reduce some duplicationErik Pilkington2019-05-311-9/+13
| | | | | | Part of https://reviews.llvm.org/D62358 llvm-svn: 362271
* Pull out repeated CI->getCalledFunction() calls. NFCI.Simon Pilgrim2019-05-061-2/+2
| | | | llvm-svn: 360070
* [SimplifyLibCalls] Simplify bcmp too.Clement Courbet2019-05-061-1/+19
| | | | | | | | | | | | | | Summary: Fixes PR40699. Reviewers: gchatelet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61585 llvm-svn: 360021
* [SimplifyLibCalls] Clean up code (NFC)Evandro Menezes2019-04-301-6/+8
| | | | | | Fix pointer check after dereferencing (PR41665). llvm-svn: 359595
* [PGO] Profile guided code size optimization.Hiroshi Yamauchi2019-04-151-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Enable some of the existing size optimizations for cold code under PGO. A ~5% code size saving in big internal app under PGO. The way it gets BFI/PSI is discussed in the RFC thread http://lists.llvm.org/pipermail/llvm-dev/2019-March/130894.html Note it doesn't currently touch loop passes. Reviewers: davidxl, eraman Reviewed By: eraman Subscribers: mgorny, javed.absar, smeenai, mehdi_amini, eraman, zzheng, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59514 llvm-svn: 358422
* [IR] Refactor attribute methods in Function class (NFC)Evandro Menezes2019-04-041-1/+1
| | | | | | | | Rename the functions that query the optimization kind attributes. Differential revision: https://reviews.llvm.org/D60287 llvm-svn: 357731
* [WebAssembly] Add Emscripten OS definition + small_printfAlon Zakai2019-04-031-0/+48
| | | | | | | | | | | | | | | The Emscripten OS provides a definition of __EMSCRIPTEN__, and also that it supports iprintf optimizations. Also define small_printf optimizations, which is a printf with float support but not long double (which in wasm can be useful since long doubles are 128 bit and force linking of float128 emulation code). This part is based on sunfish's https://reviews.llvm.org/D57620 (which can't land yet since the WASI integration isn't ready yet). Differential Revision: https://reviews.llvm.org/D60167 llvm-svn: 357552
* [SimplifyLibCalls] Simplify optimizePutsFangrui Song2019-03-121-10/+6
| | | | | | | | | | | The code might intend to replace puts("") with putchar('\n') even if the return value is used. It failed because use_empty() was used to guard the whole block. While returning '\n' (putchar('\n')) is technically correct (puts is only required to return a nonnegative number on success), doing this looks weird and there is really little benefit to optimize puts whose return value is used. So don't do that. llvm-svn: 355921
* [SimplifyLibCalls] Fix comments about fputs, memchr, and s[n]printf. NFCFangrui Song2019-03-121-5/+7
| | | | llvm-svn: 355905
* [SelectionDAG] Allow the user to specify a memeq function.Clement Courbet2019-03-081-14/+27
| | | | | | | | | | | | | | | | | | | | | | | Summary: Right now, when we encounter a string equality check, e.g. `if (memcmp(a, b, s) == 0)`, we try to expand to a comparison if `s` is a small compile-time constant, and fall back on calling `memcmp()` else. This is sub-optimal because memcmp has to compute much more than equality. This patch replaces `memcmp(a, b, s) == 0` by `bcmp(a, b, s) == 0` on platforms that support `bcmp`. `bcmp` can be made much more efficient than `memcmp` because equality compare is trivially parallel while lexicographic ordering has a chain dependency. Subscribers: fedor.sergeev, jyknight, ckennelly, gchatelet, llvm-commits Differential Revision: https://reviews.llvm.org/D56593 llvm-svn: 355672
* [opaque pointer types] Pass value type to GetElementPtr creation.James Y Knight2019-02-011-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
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-14/+20
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-011-6/+6
| | | | | | | | | 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
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-7/+8
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-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
* [SimplifyLibCalls] Fix memchr expansion for constant strings.Eli Friedman2019-01-091-1/+4
| | | | | | | | | | | | The C standard says "The memchr function locates the first occurrence of c (converted to an unsigned char)[...]". The expansion was missing the conversion to unsigned char. Fixes https://bugs.llvm.org/show_bug.cgi?id=39041 . Differential Revision: https://reviews.llvm.org/D55947 llvm-svn: 350775
* [NFC][InstCombine] Undo stray changeEvandro Menezes2018-10-191-2/+2
| | | | | | Undo stray change introduced by r344725. llvm-svn: 344814
* Add a emitUnaryFloatFnCall version that fetches the function name from TLIMikael Holmen2018-10-181-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In several places in the code we use the following pattern: if (hasUnaryFloatFn(&TLI, Ty, LibFunc_tan, LibFunc_tanf, LibFunc_tanl)) { [...] Value *Res = emitUnaryFloatFnCall(X, TLI.getName(LibFunc_tan), B, Attrs); [...] } In short, we check if there is a lib-function for a certain type, and then we _always_ fetch the name of the "double" version of the lib function and construct a call to the appropriate function, that we just checked exists, using that "double" name as a basis. This is of course a problem in cases where the target doesn't support the "double" version, but e.g. only the "float" version. In that case TLI.getName(LibFunc_tan) returns "", and emitUnaryFloatFnCall happily appends an "f" to "", and we erroneously end up with a call to a function called "f". To solve this, the above pattern is changed to if (hasUnaryFloatFn(&TLI, Ty, LibFunc_tan, LibFunc_tanf, LibFunc_tanl)) { [...] Value *Res = emitUnaryFloatFnCall(X, &TLI, LibFunc_tan, LibFunc_tanf, LibFunc_tanl, B, Attrs); [...] } I.e instead of first fetching the name of the "double" version and then letting emitUnaryFloatFnCall() add the final "f" or "l", we let emitUnaryFloatFnCall() fetch the right name from TLI. Reviewers: eli.friedman, efriedma Reviewed By: efriedma Subscribers: efriedma, bjope, llvm-commits Differential Revision: https://reviews.llvm.org/D53370 llvm-svn: 344725
* [InstCombine] Cleanup libfunc attribute inferringDavid Bolvansky2018-10-161-1/+1
| | | | | | | | | | | | Reviewers: efriedma Reviewed By: efriedma Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53338 llvm-svn: 344645
* [InstCombine] Fixed crash with aliased functionsDavid Bolvansky2018-10-131-1/+1
| | | | | | | | | | | | | | Summary: Fixes PR39177 Reviewers: spatel, jbuening Reviewed By: jbuening Subscribers: jbuening, llvm-commits Differential Revision: https://reviews.llvm.org/D53129 llvm-svn: 344454
* [InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had ↵Amara Emerson2018-10-111-10/+14
| | | | | | | | | | | | | references to it. InstCombine keeps a worklist and assumes that optimizations don't eraseFromParent() the instruction, which SimplifyLibCalls violates. This change adds a new callback to SimplifyLibCalls to let clients specify their own hander for erasing actions. Differential Revision: https://reviews.llvm.org/D52729 llvm-svn: 344251
* [InstCombine] Disable strcmp->memcmp transform for MSan.Matt Morehouse2018-09-191-1/+4
| | | | | | | | | | | | | | | | | | Summary: The strcmp->memcmp transform can make the resulting memcmp read uninitialized data, which MSan doesn't like. Resolves https://github.com/google/sanitizers/issues/993. Reviewers: eugenis, xbolva00 Reviewed By: eugenis Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D52272 llvm-svn: 342582
* [SLC] Support expanding pow(x, n+0.5) to x * x * ... * sqrt(x)Florian Hahn2018-09-031-14/+52
| | | | | | | | | | Reviewers: evandro, efriedma, spatel Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D51435 llvm-svn: 341330
* [InstCombine] Expand the simplification of pow() into exp2()Evandro Menezes2018-08-301-5/+27
| | | | | | | | | | | | | Generalize the simplification of `pow(2.0, y)` to `pow(2.0 ** n, y)` for all scalar and vector types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D49273 llvm-svn: 341095
* Revert r340947 "[InstCombine] Expand the simplification of pow() into exp2()"Reid Kleckner2018-08-291-25/+5
| | | | | | It broke the clang-cl self-host. llvm-svn: 340991
* [InstCombine] Expand the simplification of pow() with nested exp{,2}()Evandro Menezes2018-08-291-4/+21
| | | | | | | | | | | | Expand the simplification of `pow(exp{,2}(x), y)` to all FP types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D51195 llvm-svn: 340948
* [InstCombine] Expand the simplification of pow() into exp2()Evandro Menezes2018-08-291-5/+25
| | | | | | | | | | | | | Generalize the simplification of `pow(2.0, y)` to `pow(2.0 ** n, y)` for all scalar and vector types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D49273 llvm-svn: 340947
* [PATCH] [InstCombine] Fix issue in the simplification of pow() with nested ↵Evandro Menezes2018-08-271-6/+22
| | | | | | | | | | | exp{,2}() Fix the issue of duplicating the call to `exp{,2}()` when it's nested in `pow()`, as exposed by rL340462. Differential revision: https://reviews.llvm.org/D51194 llvm-svn: 340784
* [NFC] Refactor simplification of pow()Evandro Menezes2018-08-221-1/+1
| | | | llvm-svn: 340476
* [InstCombine] Refactor the simplification of pow() (NFC)Evandro Menezes2018-08-171-32/+51
| | | | | | | Refactor all cases dealing with `exp{,2,10}()` into one function in preparation for D49273. Otherwise, NFC. llvm-svn: 340061
* [InstCombine] add reflection fold for tan(-x)Sanjay Patel2018-08-161-2/+5
| | | | | | | | | This is a follow-up suggested with rL339604. For tan(), we don't have a corresponding LLVM intrinsic -- unlike sin/cos -- so this is the only way/place that we can do this fold currently. llvm-svn: 339958
* [InstCombine] Expand the simplification of pow(x, 0.5) to sqrt(x)Evandro Menezes2018-08-161-31/+20
| | | | | | | | | Expand the number of cases when `pow(x, 0.5)` is simplified into `sqrt(x)` by considering the math semantics with more granularity. Differential revision: https://reviews.llvm.org/D50036 llvm-svn: 339887
* [SimplifyLibCalls] don't drop fast-math-flags on trig reflection folds ↵Sanjay Patel2018-08-131-1/+6
| | | | | | | | | | (retry r339608) Even though this code is below a function called optimizeFloatingPointLibCall(), we apparently can't guarantee that we're dealing with FPMathOperators, so bail out immediately if that's not true. llvm-svn: 339618
* revert r339608 - [SimplifyLibCalls] don't drop fast-math-flags on trig ↵Sanjay Patel2018-08-131-3/+1
| | | | | | | | | reflection folds Can't set the builder flags without knowing this is an FPMathOperator. I'll add a test for that and try again. llvm-svn: 339609
* [SimplifyLibCalls] don't drop fast-math-flags on trig reflection foldsSanjay Patel2018-08-131-1/+3
| | | | llvm-svn: 339608
* [SimplifyLibCalls] add reflection fold for -sin(-x) (PR38458)Sanjay Patel2018-08-131-15/+27
| | | | | | | | | | This is a very partial fix for the reported problem. I suspect we do not get this fold in most motivating cases because most of the time, the libcall would have been replaced by an intrinsic, and that optimization is handled elsewhere...but maybe it should be handled here? llvm-svn: 339604
* [SimplifyLibCalls] reduce code for optimizeCos; NFCISanjay Patel2018-08-131-9/+8
| | | | llvm-svn: 339588
* [SLC] Expand simplification of pow() for vector typesEvandro Menezes2018-08-131-40/+37
| | | | | | | | Also consider vector constants when simplifying `pow()`. Differential revision: https://reviews.llvm.org/D50035 llvm-svn: 339578
* [InstCombine] Transform str(n)cmp to memcmpDavid Bolvansky2018-08-101-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Motivation examples: int strcmp_memcmp() { char buf[12]; return strcmp(buf, "key") == 0; } int strcmp_memcmp2() { char buf[12]; return strcmp(buf, "key") != 0; } int strncmp_memcmp() { char buf[12]; return strncmp(buf, "key", 3) == 0; } can be turned to memcmp. See test file for more cases. Reviewers: efriedma Reviewed By: efriedma Subscribers: spatel, llvm-commits Differential Revision: https://reviews.llvm.org/D50233 llvm-svn: 339410
* [SLC] Fix shrinking of pow()Evandro Menezes2018-08-061-13/+17
| | | | | | | | | Properly shrink `pow()` to `powf()` as a binary function and, when no other simplification applies, do not discard it. Differential revision: https://reviews.llvm.org/D50113 llvm-svn: 339046
* [SLC] Refactor shrinking of functions (NFC)Evandro Menezes2018-08-031-72/+55
| | | | | | | Merge the helper functions for shrinking unary and binary functions into a single one, while keeping all their functionality. Otherwise, NFC. llvm-svn: 338905
OpenPOWER on IntegriCloud