summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/ConstProp
Commit message (Collapse)AuthorAgeFilesLines
* [ConstantFold] fix inconsistent handling of extractelement with undef index ↵Sanjay Patel2019-10-131-1/+1
| | | | | | | | | (PR42689) Any constant other than zero was already folded to undef if the index is undef. https://bugs.llvm.org/show_bug.cgi?id=42689 llvm-svn: 374729
* [ConstProp] add tests for extractelement with undef index; NFCSanjay Patel2019-10-091-6/+27
| | | | llvm-svn: 374210
* [ConstProp] allow folding for fma that produces NaNSanjay Patel2019-09-121-25/+12
| | | | | | | | | | | | | | | | | | | | 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
* [ConstProp] add tests for fma that produce NaN; NFCSanjay Patel2019-09-111-0/+133
| | | | llvm-svn: 371621
* [ConstProp] move test file from InstSimplify; NFCSanjay Patel2019-09-111-0/+126
| | | | | | | These are constant folding tests; there is no code directly in InstSimplify for this. llvm-svn: 371619
* [ConstantFolding] Fix 'undef' folding for @llvm.[us]{add,sub}.with.overflow ↵Roman Lebedev2019-09-011-5/+8
| | | | | | | | | | | | | | | | | | | | 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
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-1735-0/+2580
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-1735-2580/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [ConstantFolding] Fix GetConstantFoldFPValue to avoid cast overflow.Bixia Zheng2019-03-221-0/+10
| | | | | | | | | | | | | | | | | | 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
* [ConstantFold] Fix misfolding fcmp of a ConstantExpr NaN with itself.Andrew Scheidecker2019-02-191-4/+4
| | | | | | | | | | | The code incorrectly inferred that the relationship of a constant expression to itself is FCMP_OEQ (ordered and equal), when it's actually FCMP_UEQ (unordered *or* equal). This change corrects that, and adds some more limited folds that can be done in this case. Differential revision: https://reviews.llvm.org/D51216 llvm-svn: 354381
* [ConstantFold] Fix misfolding of icmp with a bitcast FP second operand.Andrew Scheidecker2019-02-191-2/+15
| | | | | | | | | In the process of trying to eliminate the bitcast, this was producing a malformed icmp with FP operands. Differential revision: https://reviews.llvm.org/D51215 llvm-svn: 354380
* [ConstProp] add IR tests to show miscompiles; NFCSanjay Patel2019-02-131-0/+36
| | | | | | A fix for these is proposed in D51216. llvm-svn: 353992
* [ConstProp] add test for miscompile from bitcast transform; NFCSanjay Patel2019-02-121-2/+16
| | | | | | This problem goes with the fix in D51215. llvm-svn: 353883
* [ConstantFolding] Fold undef for integer intrinsicsNikita Popov2019-01-111-16/+8
| | | | | | | | | | | | | | | | | | | 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
* [ConstantFolding] Consolidate and extend bitcount intrinsic tests; NFCNikita Popov2018-12-201-8/+0
| | | | | | | Move constant folding tests into ConstantFolding/bitcount.ll and drop various tests in other places. Add coverage for undefs. llvm-svn: 349806
* [ConstantFolding] Add undef tests for overflow intrinsics; NFCNikita Popov2018-12-201-0/+71
| | | | llvm-svn: 349805
* [ConstantFolding] Regenerate test checks; NFCNikita Popov2018-12-201-78/+58
| | | | | | | Bring overflow-ops.ll into current format. Remove redundant entry blocks. llvm-svn: 349804
* [ConstantFolding] Handle leading zero-size elements in load foldingNikita Popov2018-12-111-0/+39
| | | | | | | | | | | | | | | | | | | | | 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
* Disable calls to *_finite and other glibc-only functions on Musl.Eli Friedman2018-11-061-0/+43
| | | | | | | | | Non-GNU environments don't have __finite_*, so treat them as unavailable. Differential Revision: https://reviews.llvm.org/D51282 llvm-svn: 346250
* [X86] Add constant folding for AVX512 versions of scalar floating point to ↵Craig Topper2018-08-121-0/+490
| | | | | | | | | | | | | | | | | | | 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
* [ConstProp] Fix calls-math-finite.ll on FreeBSDFangrui Song2018-07-261-1/+1
| | | | | | | FreeBSD's log(3.0) is less precise than glibc and musl. Let's forgive its rounding error of more than half an ulp. llvm-svn: 338009
* Make uitofp and sitofp defined on overflow.Eli Friedman2018-06-141-2/+2
| | | | | | | | | | | IEEE 754 defines the expected result on overflow. As far as I know, hardware implementations (of f16), and compiler-rt (__floatuntisf) correctly return +-Inf on overflow. And I can't think of any useful transform that would take advantage of overflow being undefined here. Differential Revision: https://reviews.llvm.org/D47807 llvm-svn: 334777
* [ConstProp] move tests for fp <--> int; NFCSanjay Patel2018-06-061-0/+40
| | | | | | | | | | These were added for D5603 / rL219542, and there's a proposal to change one side in D47807. These are tests of constant propagation, so they shouldn't have ever been tested/housed under InstCombine. llvm-svn: 334107
* [TargetLibraryInfo] fix finite mathlib function availabilitySanjay Patel2018-01-081-16/+39
| | | | | | | | | | | This patch was part of: https://reviews.llvm.org/D41338 ...but we can expose the bug in IR via constant propagation as shown in the test. Unless the triple includes 'linux', we should not fold these because the functions don't exist on other platforms (yet?). llvm-svn: 322010
* [X86] Replace 'REQUIRES: x86' in tests with 'REQUIRES: ↵Craig Topper2017-06-041-1/+1
| | | | | | x86-registered-target' which seems to be the correct way to make them run on an x86 build. llvm-svn: 304682
* Fix two tests that weren't correctly copied.Daniel Jasper2017-05-141-1/+0
| | | | | | | One didn't correctly fine the regex variable, the other still had a RUN line for FNOBUILTIN-checks, which weren't copied to the file. llvm-svn: 303025
* ConstProp: Split x86 SSE intrinsic tests out of calls.llJustin Bogner2017-05-132-206/+209
| | | | | | | This allows us to mark this as `REQUIRES: x86`, since it uses x86 target specific intrinsics. llvm-svn: 302980
* [ConstantFolding] Add folding for various math '__<func>_finite' routines ↵Andrew Kaylor2017-05-121-0/+83
| | | | | | | | | | generated from -ffast-math Patch by Chris Chrulski Differential Revision: https://reviews.llvm.org/D31788 llvm-svn: 302956
* opt: Rename -default-data-layout flag to -data-layout and make it always ↵Peter Collingbourne2017-02-171-2/+2
| | | | | | | | | | override the layout. There isn't much point in a flag that only works if the data layout is empty. Differential Revision: https://reviews.llvm.org/D30014 llvm-svn: 295468
* [InstCombiner] Simplify lib calls to `round{,f}`Bryant Wong2016-12-261-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D28110 llvm-svn: 290542
* Don't remove side effecting instructions due to ConstantFoldInstructionDavid Majnemer2016-07-221-40/+40
| | | | | | | | | Just because we can constant fold the result of an instruction does not imply that we can delete the instruction. It may have side effects. This fixes PR28655. llvm-svn: 276389
* [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using ↵Simon Pilgrim2016-07-191-3/+5
| | | | | | | | | | | | | | | | | | generic IR D20859 and D20860 attempted to replace the SSE (V)CVTTPS2DQ and VCVTTPD2DQ truncating conversions with generic IR instead. It turns out that the behaviour of these intrinsics is different enough from generic IR that this will cause problems, INF/NAN/out of range values are guaranteed to result in a 0x80000000 value - which plays havoc with constant folding which converts them to either zero or UNDEF. This is also an issue with the scalar implementations (which were already generic IR and what I was trying to match). This patch changes both scalar and packed versions back to using x86-specific builtins. It also deals with the other scalar conversion cases that are runtime rounding mode dependent and can have similar issues with constant folding. A companion clang patch is at D22105 Differential Revision: https://reviews.llvm.org/D22106 llvm-svn: 275981
* [X86][SSE] Improve constant folding tests for CVTSD/CVTSS/CVTTSD/CVTTSSSimon Pilgrim2016-07-081-17/+188
| | | | | | As discussed on D22106, improve the testing for constant folding sse scalar conversion intrinsics to ensure we are correctly handling special/out of range cases llvm-svn: 274846
* Revert "[SCCP] Partially propagate informations when the input is not fully ↵Davide Italiano2016-05-111-1/+0
| | | | | | | | defined." This reverts commit r269105 as it caused PR27712. llvm-svn: 269252
* [SCCP] Partially propagate informations when the input is not fully defined.Davide Italiano2016-05-101-0/+1
| | | | | | | | | | With this patch: %r1 = lshr i64 -1, 4294967296 -> undef Before this patch: %r1 = lshr i64 -1, 4294967296 -> 0 llvm-svn: 269105
* IR: Make ConstantDataArray::getFP actually return a ConstantDataArrayJustin Bogner2015-12-091-0/+10
| | | | | | | | | | The ConstantDataArray::getFP(LLVMContext &, ArrayRef<uint16_t>) overload has had a typo in it since it was written, where it will create a Vector instead of an Array. This obviously doesn't work at all, but it turns out that until r254991 there weren't actually any callers of this overload. Fix the typo and add some test coverage. llvm-svn: 255157
* [test] (NFC) Simplify Transforms/ConstProp/calls.llVedant Kumar2015-08-281-680/+116
| | | | | | Differential Revision: http://reviews.llvm.org/D12421 llvm-svn: 246312
* Enable constant propagation for more math functionsErik Schnetter2015-08-271-41/+677
| | | | | | | | | | | | Constant propagation for single precision math functions (such as tanf) is already working, but was not enabled. This patch enables these for many single-precision functions, and adds respective test cases. Newly handled functions: acosf asinf atanf atan2f ceilf coshf expf exp2f fabsf floorf fmodf logf log10f powf sinhf tanf tanhf llvm-svn: 246194
* Revert 246186; still breaks on some systemsErik Schnetter2015-08-271-677/+41
| | | | llvm-svn: 246191
* Enable constant propagation for more math functionsErik Schnetter2015-08-271-41/+677
| | | | | | | | | | | | Constant propagation for single precision math functions (such as tanf) is already working, but was not enabled. This patch enables these for many single-precision functions, and adds respective test cases. Newly handled functions: acosf asinf atanf atan2f ceilf coshf expf exp2f fabsf floorf fmodf logf log10f powf sinhf tanf tanhf llvm-svn: 246186
* Revert r246158 since it breaks LLVM.Transforms/ConstProp.calls.llErik Schnetter2015-08-271-636/+41
| | | | llvm-svn: 246166
* Enable constant propagation for more math functionsErik Schnetter2015-08-271-41/+636
| | | | | | | | | | | | Constant propagation for single precision math functions (such as tanf) is already working, but was not enabled. This patch enables these for many single-precision functions, and adds respective test cases. Newly handled functions: acosf asinf atanf atan2f ceilf coshf expf exp2f fabsf floorf fmodf logf log10f powf sinhf tanf tanhf llvm-svn: 246158
* Fix assert when inlining a constantexpr addrspacecastMatt Arsenault2015-07-271-2/+5
| | | | | | | | | | | | The pointer size of the addrspacecasted pointer might not have matched, so this would have hit an assert in accumulateConstantOffset. I think this was here to allow constant folding of a load of an addrspacecasted constant. Accumulating the offset through the addrspacecast doesn't make much sense, so something else is necessary to allow folding the load through this cast. llvm-svn: 243300
* [ConstantFolding] Fix wrong folding of intrinsic 'convert.from.fp16'.Andrea Di Biagio2015-05-141-0/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Function 'ConstantFoldScalarCall' (in ConstantFolding.cpp) works under the wrong assumption that a call to 'convert.from.fp16' returns a value of type 'float'. However, intrinsic 'convert.from.fp16' can be overloaded; for example, we can call 'convert.from.fp16.f64' to convert from half to double; etc. Before this patch, the following example would have triggered an assertion failure in opt (with -constprop): ``` define double @foo() { entry: %0 = call double @llvm.convert.from.fp16.f64(i16 0) ret double %0 } ``` This patch fixes the problem in ConstantFolding.cpp. When folding a call to convert.from.fp16, we perform a different kind of conversion based on the call return type. Added test 'Transform/ConstProp/convert-from-fp16.ll'. Differential Revision: http://reviews.llvm.org/D9771 llvm-svn: 237377
* Constfold insertelement to undef when index is out-of-boundsPawel Bylica2015-04-271-1/+21
| | | | | | | | | | | | | | | | | | | Summary: This patch adds constant folding of insertelement instruction to undef value when index operand is constant and is not less than vector size or is undef. InstCombine does not support this case, but I'm happy to add it there also if this change is accepted. Test Plan: Unittests and regression tests for ConstProp pass. Reviewers: majnemer Reviewed By: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9287 llvm-svn: 235854
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-03-133-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gep operator Similar to gep (r230786) and load (r230794) changes. Similar migration script can be used to update test cases, which successfully migrated all of LLVM and Polly, but about 4 test cases needed manually changes in Clang. (this script will read the contents of stdin and massage it into stdout - wrap it in the 'apply.sh' script shown in previous commits + xargs to apply it over a large set of test cases) import fileinput import sys import re rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL) def conv(match): line = match.group(1) line += match.group(4) line += ", " line += match.group(2) return line line = sys.stdin.read() off = 0 for match in re.finditer(rep, line): sys.stdout.write(line[off:match.start()]) sys.stdout.write(conv(match)) off = match.end() sys.stdout.write(line[off:]) llvm-svn: 232184
* ConstantFold: Fix big shift constant foldingDavid Majnemer2015-03-131-0/+69
| | | | | | | | | | | | | Constant folding for shift IR instructions ignores all bits above 32 of second argument (shift amount). Because of that, some undef results are not recognized and APInt can raise an assert failure if second argument has more than 64 bits. Patch by Paweł Bylica! Differential Revision: http://reviews.llvm.org/D7701 llvm-svn: 232176
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-02-271-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getelementptr instruction One of several parallel first steps to remove the target type of pointers, replacing them with a single opaque pointer type. This adds an explicit type parameter to the gep instruction so that when the first parameter becomes an opaque pointer type, the type to gep through is still available to the instructions. * This doesn't modify gep operators, only instructions (operators will be handled separately) * Textual IR changes only. Bitcode (including upgrade) and changing the in-memory representation will be in separate changes. * geps of vectors are transformed as: getelementptr <4 x float*> %x, ... ->getelementptr float, <4 x float*> %x, ... Then, once the opaque pointer type is introduced, this will ultimately look like: getelementptr float, <4 x ptr> %x with the unambiguous interpretation that it is a vector of pointers to float. * address spaces remain on the pointer, not the type: getelementptr float addrspace(1)* %x ->getelementptr float, float addrspace(1)* %x Then, eventually: getelementptr float, ptr addrspace(1) %x Importantly, the massive amount of test case churn has been automated by same crappy python code. I had to manually update a few test cases that wouldn't fit the script's model (r228970,r229196,r229197,r229198). The python script just massages stdin and writes the result to stdout, I then wrapped that in a shell script to handle replacing files, then using the usual find+xargs to migrate all the files. update.py: import fileinput import sys import re ibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") normrep = re.compile( r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") def conv(match, line): if not match: return line line = match.groups()[0] if len(match.groups()[5]) == 0: line += match.groups()[2] line += match.groups()[3] line += ", " line += match.groups()[1] line += "\n" return line for line in sys.stdin: if line.find("getelementptr ") == line.find("getelementptr inbounds"): if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("): line = conv(re.match(ibrep, line), line) elif line.find("getelementptr ") != line.find("getelementptr ("): line = conv(re.match(normrep, line), line) sys.stdout.write(line) apply.sh: for name in "$@" do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp" done The actual commands: From llvm/src: find test/ -name *.ll | xargs ./apply.sh From llvm/src/tools/clang: find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}" From llvm/src/tools/polly: find test/ -name *.ll | xargs ./apply.sh After that, check-all (with llvm, clang, clang-tools-extra, lld, compiler-rt, and polly all checked out). The extra 'rm' in the apply.sh script is due to a few files in clang's test suite using interesting unicode stuff that my python script was throwing exceptions on. None of those files needed to be migrated, so it seemed sufficient to ignore those cases. Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7636 llvm-svn: 230786
* Avoid conversion to float when creating ConstantDataArray/ConstantDataVector.Rafael Espindola2015-02-192-0/+21
| | | | | | Patch by Raoux, Thomas F! llvm-svn: 229864
OpenPOWER on IntegriCloud