summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* ValueTracking: Add tests for isKnownNeverNaNMatt Arsenault2018-08-171-2/+341
| | | | llvm-svn: 340090
* [NFC] Expand test cases for simplifying pow()Evandro Menezes2018-08-172-3/+96
| | | | | | In prepatration for the improvements that D49273 enables. llvm-svn: 340060
* [NewGVN] Add tests for r340031.Florian Hahn2018-08-172-0/+260
| | | | llvm-svn: 340032
* [InstrSimplify,NewGVN] Add option to ignore additional instr info when ↵Florian Hahn2018-08-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | simplifying. NewGVN uses InstructionSimplify for simplifications of leaders of congruence classes. It is not guaranteed that the metadata or other flags/keywords (like nsw or exact) of the leader is available for all members in a congruence class, so we cannot use it for simplification. This patch adds a InstrInfoQuery struct with a boolean field UseInstrInfo (which defaults to true to keep the current behavior as default) and a set of helper methods to get metadata/keywords for a given instruction, if UseInstrInfo is true. The whole thing might need a better name, to avoid confusion with TargetInstrInfo but I am not sure what a better name would be. The current patch threads through InstrInfoQuery to the required places, which is messier then it would need to be, if InstructionSimplify and ValueTracking would share the same Query struct. The reason I added it as a separate struct is that it can be shared between InstructionSimplify and ValueTracking's query objects. Also, some places do not need a full query object, just the InstrInfoQuery. It also updates some interfaces that do not take a Query object, but a set of optional parameters to take an additional boolean UseInstrInfo. See https://bugs.llvm.org/show_bug.cgi?id=37540. Reviewers: dberlin, davide, efriedma, sebpop, hiraditya Reviewed By: hiraditya Differential Revision: https://reviews.llvm.org/D47143 llvm-svn: 340031
* [AtomicExpandPass] Widen partword atomicrmw or/xor/and before tryExpandAtomicRMWAlex Bradbury2018-08-171-0/+25
| | | | | | | | | | | | | | | | | | | This patch performs a widening transformation of bitwise atomicrmw {or,xor,and} and applies it prior to tryExpandAtomicRMW. This operates similarly to convertCmpXchgToIntegerType. For these operations, the i8/i16 atomicrmw can be implemented in terms of the 32-bit atomicrmw by appropriately manipulating the operands. There is no functional change for the handling of partword or/xor, but the transformation for partword 'and' is new. The advantage of performing this transformation early is that the same code-path can be used regardless of the approach used to expand the atomicrmw (AtomicExpansionKind). i.e. the same logic is used for AtomicExpansionKind::CmpXchg and can also be used by the intrinsic-based expansion in D47882. Differential Revision: https://reviews.llvm.org/D48129 llvm-svn: 340027
* [LICM] Add a diagnostic analysis for identifying alias informationAnna Thomas2018-08-173-8/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, in LICM, we use the alias set tracker to identify if the instruction (we're interested in hoisting) aliases with instruction that modifies that memory location. This patch adds an LICM alias analysis diagnostic tool that checks the mod ref info of the instruction we are interested in hoisting/sinking, with every instruction in the loop. Because of O(N^2) complexity this is now only a diagnostic tool to show the limitation we have with the alias set tracker and is OFF by default. Test cases show the difference with the diagnostic analysis tool, where we're able to hoist out loads and readonly + argmemonly calls from the loop, where the alias set tracker analysis is not able to hoist these instructions out. Reviewers: reames, mkazantsev, fedor.sergeev, hfinkel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50854 llvm-svn: 340026
* [MustExecute] Fix algorithmic bug in isGuaranteedToExecute. PR38514Max Kazantsev2018-08-171-4/+3
| | | | | | | | | | | | | | | | | | | | | The description of `isGuaranteedToExecute` does not correspond to its implementation. According to description, it should return `true` if an instruction is executed under the assumption that its loop is *entered*. However there is a sophisticated alrogithm inside that tries to prove that the instruction is executed if the loop is *exited*, which is not the same thing for infinite loops. There is an attempt to protect from dealing with infinite loops by prohibiting loops without exit blocks, however an infinite loop can have exit blocks. As result of that, MustExecute can falsely consider some blocks that are never entered as mustexec, and LICM can hoist dangerous instructions out of them basing on this fact. This may introduce UB to programs which did not contain it initially. This patch removes the problematic algorithm and replaced it with a one which tries to prove what is required in description. Differential Revision: https://reviews.llvm.org/D50558 Reviewed By: reames llvm-svn: 339984
* [NFC] Add tests to ensure that improvement of MustThrow analysis will not ↵Max Kazantsev2018-08-171-0/+91
| | | | | | lead to problems in future llvm-svn: 339983
* [InstCombine] add reflection fold for tan(-x)Sanjay Patel2018-08-161-6/+6
| | | | | | | | | 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] add tests for tan with negated arg; NFCSanjay Patel2018-08-161-13/+40
| | | | llvm-svn: 339953
* add a missed case for binary op FMF propagation under select foldsMichael Berg2018-08-162-2/+2
| | | | llvm-svn: 339938
* [MemLoc] Fix a bug causing any use of invariant.end to crash in LICMPhilip Reames2018-08-161-3/+1
| | | | | | The fix is fairly simple, but is says something unpleasant about the usage and testing of invariant.start/end scopes that this went undetected. To put this in perspective, *any* invariant.end in a loop flowing through LICM crashed. I haven't bothered to figure out just how far back this goes, but it's not caused by any of the recent changes. We're probably talking months if not years. llvm-svn: 339936
* [NFC] Fix typo in test casesEvandro Menezes2018-08-162-4/+3
| | | | llvm-svn: 339900
* [InstCombine] Expand the simplification of pow(x, 0.5) to sqrt(x)Evandro Menezes2018-08-162-66/+82
| | | | | | | | | 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
* [InstCombine] move vector compare before same-shuffled opsSanjay Patel2018-08-161-11/+8
| | | | | | | This is a step towards fixing PR37463: https://bugs.llvm.org/show_bug.cgi?id=37463 llvm-svn: 339875
* [CodeGenPrepare] Add BothExtension type to PromotedInstsGuozhi Wei2018-08-151-0/+25
| | | | | | | | | | | | This patch fixes PR38125. Instruction extension types are recorded in PromotedInsts, it can be used later in function canGetThrough. If an instruction has two users with different extension types, it will be inserted into PromotedInsts two times in function promoteOperandForOther. The second one overwrites the first one, and the final extension type is wrong, later causes problem in canGetThrough. This patch changes the simple bool extension type to 2-bit enum type, add a BothExtension type in addition to zero/sign extension. When an user sees BothExtension for an instruction, it actually knows nothing about how that instruction is extended. Differential Revision: https://reviews.llvm.org/D49512 llvm-svn: 339822
* AMDGPU: Stop producing icmp/fcmp intrinsics with invalid typesMatt Arsenault2018-08-151-0/+149
| | | | llvm-svn: 339815
* [InstCombine] Fix IC trying to create a xor of pointer types.Amara Emerson2018-08-151-0/+13
| | | | | | | | rdar://42473741 Differential Revision: https://reviews.llvm.org/D50775 llvm-svn: 339796
* [AliasSetTracker] Do not treat experimental_guard intrinsic as memory ↵Max Kazantsev2018-08-151-0/+26
| | | | | | | | | | | | | | | | writing instruction The `experimental_guard` intrinsic has memory write semantics to model the thread-exiting logic, but does not do any actual writes to memory. Currently, `AliasSetTracker` treats it as a normal memory write. As result, a loop-invariant load cannot be hoisted out of loop because the guard may possibly alias with it. This patch makes `AliasSetTracker` so that it doesn't treat guards as memory writes. Differential Revision: https://reviews.llvm.org/D50497 Reviewed By: reames llvm-svn: 339753
* [InstCombine] fix typos in tests; NFCSanjay Patel2018-08-141-6/+6
| | | | | | See D50036. llvm-svn: 339713
* [InstCombine] add tests for pow->sqrt; NFCSanjay Patel2018-08-141-26/+239
| | | | | | D50036 should fix the missed optimizations. llvm-svn: 339711
* [LV] Teach about non header phis that have uses outside the loopAnna Thomas2018-08-141-6/+231
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch teaches the loop vectorizer to vectorize loops with non header phis that have have outside uses. This is because the iteration dependence distance for these phis can be widened upto VF (similar to how we do for induction/reduction) if they do not have a cyclic dependence with header phis. When identifying reduction/induction/first order recurrence header phis, we already identify if there are any cyclic dependencies that prevents vectorization. The vectorizer is taught to extract the last element from the vectorized phi and update the scalar loop exit block phi to contain this extracted element from the vector loop. This patch can be extended to vectorize loops where instructions other than phis have outside uses. Reviewers: Ayal, mkuper, mssimpso, efriedma Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50579 llvm-svn: 339703
* [NFC] Tests for select with binop fold - FP opcodesDavid Bolvansky2018-08-141-20/+17
| | | | llvm-svn: 339692
* [InstCombine] regenerate checks; NFCSanjay Patel2018-08-142-9/+12
| | | | llvm-svn: 339683
* [InstCombine] regenerate checks; NFCSanjay Patel2018-08-142-121/+154
| | | | llvm-svn: 339681
* [X86] Constant folding of adds/subs intrinsicsTomasz Krupa2018-08-141-0/+351
| | | | | | | | | | | | | | Summary: This adds constant folding of signed add/sub with saturation intrinsics. Reviewers: craig.topper, spatel, RKSimon, chandlerc, efriedma Reviewed By: craig.topper Subscribers: rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D50499 llvm-svn: 339659
* [BasicAA] Don't assume tail calls with byval don't alias allocasReid Kleckner2018-08-141-0/+23
| | | | | | | | | | | | | | | | | | | | Summary: Calls marked 'tail' cannot read or write allocas from the current frame because the current frame might be destroyed by the time they run. However, a tail call may use an alloca with byval. Calling with byval copies the contents of the alloca into argument registers or stack slots, so there is no lifetime issue. Tail calls never modify allocas, so we can return just ModRefInfo::Ref. Fixes PR38466, a longstanding bug. Reviewers: hfinkel, nlewycky, gbiv, george.burgess.iv Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50679 llvm-svn: 339636
* [InstCombine] Re-land: Optimize redundant 'signed truncation check pattern'.Roman Lebedev2018-08-131-57/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This comes with `Implicit Conversion Sanitizer - integer sign change` (D50250): ``` signed char test(unsigned int x) { return x; } ``` `clang++ -fsanitize=implicit-conversion -S -emit-llvm -o - /tmp/test.cpp -O3` * Old: {F6904292} * With this patch: {F6904294} General pattern: X & Y Where `Y` is checking that all the high bits (covered by a mask `4294967168`) are uniform, i.e. `%arg & 4294967168` can be either `4294967168` or `0` Pattern can be one of: %t = add i32 %arg, 128 %r = icmp ult i32 %t, 256 Or %t0 = shl i32 %arg, 24 %t1 = ashr i32 %t0, 24 %r = icmp eq i32 %t1, %arg Or %t0 = trunc i32 %arg to i8 %t1 = sext i8 %t0 to i32 %r = icmp eq i32 %t1, %arg This pattern is a signed truncation check. And `X` is checking that some bit in that same mask is zero. I.e. can be one of: %r = icmp sgt i32 %arg, -1 Or %t = and i32 %arg, 2147483648 %r = icmp eq i32 %t, 0 Since we are checking that all the bits in that mask are the same, and a particular bit is zero, what we are really checking is that all the masked bits are zero. So this should be transformed to: %r = icmp ult i32 %arg, 128 The transform itself ended up being rather horrible, even though i omitted some cases. Surely there is some infrastructure that can help clean this up that i missed? https://rise4fun.com/Alive/3Ou The initial commit (rL339610) was reverted, since the first assert was being triggered. The @positive_with_extra_and test now has coverage for that case. Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: RKSimon, erichkeane, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D50465 llvm-svn: 339621
* [NFC][InstCombine] Add a test for D50465 that used to assertRoman Lebedev2018-08-131-0/+19
| | | | | | | This is valid to fold, too. https://rise4fun.com/Alive/0lz llvm-svn: 339619
* [SimplifyLibCalls] don't drop fast-math-flags on trig reflection folds ↵Sanjay Patel2018-08-131-1/+12
| | | | | | | | | | (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 "[InstCombine] Optimize redundant 'signed truncation check pattern'."Roman Lebedev2018-08-131-22/+51
| | | | | | | | | At least one buildbot was able to actually trigger that assert on the top of the function. Will investigate. This reverts commit r339610. llvm-svn: 339612
* [InstCombine] Optimize redundant 'signed truncation check pattern'.Roman Lebedev2018-08-131-51/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This comes with `Implicit Conversion Sanitizer - integer sign change` (D50250): ``` signed char test(unsigned int x) { return x; } ``` `clang++ -fsanitize=implicit-conversion -S -emit-llvm -o - /tmp/test.cpp -O3` * Old: {F6904292} * With this patch: {F6904294} General pattern: X & Y Where `Y` is checking that all the high bits (covered by a mask `4294967168`) are uniform, i.e. `%arg & 4294967168` can be either `4294967168` or `0` Pattern can be one of: %t = add i32 %arg, 128 %r = icmp ult i32 %t, 256 Or %t0 = shl i32 %arg, 24 %t1 = ashr i32 %t0, 24 %r = icmp eq i32 %t1, %arg Or %t0 = trunc i32 %arg to i8 %t1 = sext i8 %t0 to i32 %r = icmp eq i32 %t1, %arg This pattern is a signed truncation check. And `X` is checking that some bit in that same mask is zero. I.e. can be one of: %r = icmp sgt i32 %arg, -1 Or %t = and i32 %arg, 2147483648 %r = icmp eq i32 %t, 0 Since we are checking that all the bits in that mask are the same, and a particular bit is zero, what we are really checking is that all the masked bits are zero. So this should be transformed to: %r = icmp ult i32 %arg, 128 https://rise4fun.com/Alive/3Ou Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: RKSimon, erichkeane, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D50465 llvm-svn: 339610
* revert r339608 - [SimplifyLibCalls] don't drop fast-math-flags on trig ↵Sanjay Patel2018-08-131-12/+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/+12
| | | | llvm-svn: 339608
* NFC: Add a test to LV showing that reduction is not possible when reduction ↵Anna Thomas2018-08-131-0/+39
| | | | | | | | | | | | var is reset in the loop Added a test case to reduction showing where it's illegal to identify vectorize a loop. Resetting the reduction var during loop iterations disallows us from widening the dependency cycle to VF, thereby making it illegal to vectorize the loop. llvm-svn: 339605
* [SimplifyLibCalls] add reflection fold for -sin(-x) (PR38458)Sanjay Patel2018-08-131-10/+8
| | | | | | | | | | 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
* [InstCombine][NFC] Tests for 'signed truncation check' optimizationRoman Lebedev2018-08-131-0/+634
| | | | | | | | See D50465 for the actual opt itself. Differential Revision: https://reviews.llvm.org/D50464 llvm-svn: 339602
* [InstCombine] add more tests for trig reflections; NFC (PR38458)Sanjay Patel2018-08-131-8/+92
| | | | llvm-svn: 339598
* [InstCombine] Limit simplifyAllocaArraySize constant folding to values that ↵Simon Pilgrim2018-08-131-0/+16
| | | | | | | | fit into a uint64_t Fixes OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5223 llvm-svn: 339584
* [InstCombine] auto-generate full checks and add cos intrinsic test; NFCSanjay Patel2018-08-131-17/+34
| | | | llvm-svn: 339579
* [SLC] Expand simplification of pow() for vector typesEvandro Menezes2018-08-133-61/+62
| | | | | | | | Also consider vector constants when simplifying `pow()`. Differential revision: https://reviews.llvm.org/D50035 llvm-svn: 339578
* [GuardWidening] Widen very likely non-taken br instructionsMax Kazantsev2018-08-131-2/+459
| | | | | | | | | | This is a second part of D49974 that handles widening of conditional branches that have very likely `false` branch. Differential Revision: https://reviews.llvm.org/D50040 Reviewed By: reames llvm-svn: 339537
* [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
* [NFC] Fixed build, updated testsDavid Bolvansky2018-08-121-2/+1
| | | | llvm-svn: 339524
* [NFC] Renamed test fileDavid Bolvansky2018-08-121-0/+0
| | | | llvm-svn: 339523
* [InstCombine] Fold Select with binary op - non-commutative opcodesDavid Bolvansky2018-08-121-18/+9
| | | | | | | | | | | | | | | | | | | Summary: Basic version was merged - https://reviews.llvm.org/D49954 This adds support for FP & non-commutative opcodes Precommited tests: https://reviews.llvm.org/rL338727 Reviewers: spatel, lebedev.ri Reviewed By: spatel Subscribers: jfb Differential Revision: https://reviews.llvm.org/D50190 llvm-svn: 339520
* [InstCombine] fix/enhance fadd/fsub factorizationSanjay Patel2018-08-121-77/+53
| | | | | | | | | | | | | (X * Z) + (Y * Z) --> (X + Y) * Z (X * Z) - (Y * Z) --> (X - Y) * Z (X / Z) + (Y / Z) --> (X + Y) / Z (X / Z) - (Y / Z) --> (X - Y) / Z The existing code that implemented these folds failed to optimize vectors, and it transformed code with multiple uses when it should not have. llvm-svn: 339519
* [InstCombine] move/add tests for fadd/fsub factorization; NFCSanjay Patel2018-08-122-373/+497
| | | | llvm-svn: 339518
* [UnJ] Improve explicit loop count checksDavid Green2018-08-111-0/+144
| | | | | | | | | | | | | Try to improve the computed counts when it has been explicitly set by a pragma or command line option. This moves the code around, so that first call to computeUnrollCount to get a sensible count and override that if explicit unroll and jam counts are specified. Also added some extra debug messages for when unroll and jamming is disabled. Differential Revision: https://reviews.llvm.org/D50075 llvm-svn: 339501
* [LICM] Hoist assumes out of loopsPhilip Reames2018-08-101-1/+1
| | | | | | | | If we have an assume which is known to execute and whose operand is invariant, we can lift that into the pre-header. So long as we don't change which paths the assume executes on, this is a legal transformation. It's likely to be a useful canonicalization as other transforms only look for dominating assumes. Differential Revision: https://reviews.llvm.org/D50364 llvm-svn: 339481
OpenPOWER on IntegriCloud