- Sep 21, 2021
-
-
Sanjay Patel authored
-
Simon Pilgrim authored
If getAggregateElement() returns null for any element, early out as otherwise we will assert when creating a new constant vector Fixes PR51824 + ; OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38057
-
Usman Nadeem authored
Differential Revision: https://reviews.llvm.org/D109808 Change-Id: I1a10d2bc33acbe0ea353c6cb3d077851391fe73e
-
- Sep 20, 2021
-
-
Nikita Popov authored
We implement logic to convert a byte offset into a sequence of GEP indices for that offset in a number of places. This patch adds a DataLayout::getGEPIndicesForOffset() method, which implements the core logic. I've updated SROA, ConstantFolding and InstCombine to use it, and there's a few more places where it looks relevant. Differential Revision: https://reviews.llvm.org/D110043
-
David Sherwood authored
In ValueTracking.cpp we use a function called computeKnownBitsFromOperator to determine the known bits of a value. For the vscale intrinsic if the function contains the vscale_range attribute we can use the maximum and minimum values of vscale to determine some known zero and one bits. This should help to improve code quality by allowing certain optimisations to take place. Tests added here: Transforms/InstCombine/icmp-vscale.ll Differential Revision: https://reviews.llvm.org/D109883
-
- Sep 19, 2021
-
-
Sanjay Patel authored
If we transform these, we have to propagate no-wrap/undef carefully.
-
- Sep 18, 2021
-
-
Nikita Popov authored
Missed this one in 80110aaf. This is another test mixing up alias scopes and alias scope lists.
-
Nikita Popov authored
Mostly this fixes cases where !noalias or !alias.scope were passed a scope rather than a scope list. In some cases I opted to drop the metadata entirely instead, because it is not really relevant to the test.
-
Usman Nadeem authored
Change-Id: Iae9bf18619e4926301a866c7e2bd38ced524804e
-
Usman Nadeem authored
zip1(uzp1(A, B), uzp2(A, B)) --> A zip2(uzp1(A, B), uzp2(A, B)) --> B Differential Revision: https://reviews.llvm.org/D109666 Change-Id: I4a6578db2fcef9ff71ad0e77b9fe08354e6dbfcd
-
- Sep 17, 2021
-
-
Sanjay Patel authored
-
Dávid Bolvanský authored
-
Sanjay Patel authored
Mostly cosmetic diffs, but the use of m_APInt matches splat constants.
-
Sanjay Patel authored
-
- Sep 16, 2021
-
-
Dávid Bolvanský authored
If power is even: powi(-x, p) -> powi(x, p) powi(fabs(x), p) -> powi(x, p) powi(copysign(x, y), p) -> powi(x, p)
-
Dávid Bolvanský authored
-
Anna Thomas authored
This reverts commit 4ac4e521. There are couple of test failures, which needs update of the test cases. Doing a clean revert and will recommit the change along with fixed testcases.
-
- Sep 15, 2021
-
-
Anna Thomas authored
This patch allows sinking an instruction which can have multiple uses in a single user. We were previously over-restrictive by looking for exactly one use, rather than one user. Also, the API for retrieving undroppable user has been updated accordingly since in both usecases (Attributor and InstCombine), we seem to care about the user, rather than the use. Reviewed-By: nikic Differential Revision: https://reviews.llvm.org/D109700
-
Sanjay Patel authored
I was wondering how instcombine does on the examples in D109236, and we're missing a basic transform: inselt (ext X), (ext Y), Index --> ext (inselt X, Y, Index) https://alive2.llvm.org/ce/z/z2aBu9 Note that there are several possible extensions of this fold (see TODO comments). Differential Revision: https://reviews.llvm.org/D109537
-
Anna Thomas authored
Updated check lines. Tests precommitted from D109700.
-
Filipp Zhinkin authored
Enabled mul folding optimization that was previously disabled by being incorrect. To preserve correctness, mul's operand that is not compared with zero in select's condition is now frozen. Related bug: https://bugs.llvm.org/show_bug.cgi?id=51286 Correctness: https://alive2.llvm.org/ce/z/bHef7J https://alive2.llvm.org/ce/z/QcR7sf https://alive2.llvm.org/ce/z/vvBLzt https://alive2.llvm.org/ce/z/jGDXgq https://alive2.llvm.org/ce/z/3Pe8Z4 https://alive2.llvm.org/ce/z/LGga8M https://alive2.llvm.org/ce/z/CTG5fs Differential Revision: https://reviews.llvm.org/D108408
-
- Sep 14, 2021
-
-
David Green authored
The class of instructions that write to narrow top/bottom lanes only demand the even or odd elements of the input lanes. Which means that a pair of VMOVNT; VMOVNB demands no lanes from the original input. This teaches that to instcombine from the target hooks available through ARMTTIImpl. Differential Revision: https://reviews.llvm.org/D109325
-
- Sep 13, 2021
-
-
Simon Pilgrim authored
-
- Sep 12, 2021
-
-
Sanjay Patel authored
https://alive2.llvm.org/ce/z/_AivbM This case seems clear since we can reduce instruction count and avoid an intermediate type change, but we might want to use mask-and-compare for other sequences. Currently, we can generate more instructions on some related patterns by trying to use bit-hacks instead of mask+cmp, so something is not behaving as expected.
-
- Sep 11, 2021
-
-
Sanjay Patel authored
Follow-up for post-commit suggestion on: 28afaed6 The comments were partly copied from the original code, but not updated to match the new code.
-
Sanjay Patel authored
This is a translation of the existing code to handle the intrinsics and another step towards D98152. https://alive2.llvm.org/ce/z/jA7eBC This pattern is already handled by underlying folds if there are less uses, so the minimal tests in this case have extra uses. The larger cmyk tests show the motivation - when combined with other folds, we invert a larger sequence and eliminate 'not' ops.
-
Usman Nadeem authored
Revert "Revert "[AArch64][SVE][InstCombine] Canonicalize aarch64_sve_dup_x intrinsic to IR splat operation"" This reverts commit eee7d225. Effectively relanding 98c37247 after fixing the failing tests. Change-Id: I5d7461aeb820a2d5f1895457d824a8de4d316ee5
-
- Sep 10, 2021
-
-
Usman Nadeem authored
This reverts commit 98c37247.
-
Usman Nadeem authored
Differential Revision: https://reviews.llvm.org/D109118 Change-Id: I47adc1984a54bea02bf5a0a767b765afe7e16aa3
-
Sanjay Patel authored
-
Nikita Popov authored
Currently, opaque pointers are supported in two forms: The -force-opaque-pointers mode, where all pointers are opaque and typed pointers do not exist. And as a simple ptr type that can coexist with typed pointers. This patch removes support for the mixed mode. You either get typed pointers, or you get opaque pointers, but not both. In the (current) default mode, using ptr is forbidden. In -opaque-pointers mode, all pointers are opaque. The motivation here is that the mixed mode introduces additional issues that don't exist in fully opaque mode. D105155 is an example of a design problem. Looking at D109259, it would probably need additional work to support mixed mode (e.g. to generate GEPs for typed base but opaque result). Mixed mode will also end up inserting many casts between i8* and ptr, which would require significant additional work to consistently avoid. I don't think the mixed mode is particularly valuable, as it doesn't align with our end goal. The only thing I've found it to be moderately useful for is adding some opaque pointer tests in between typed pointer tests, but I think we can live without that. Differential Revision: https://reviews.llvm.org/D109290
-
Filipp Zhinkin authored
These are the tests for D108408 with current baseline results.
-
- Sep 09, 2021
-
-
Sanjay Patel authored
-
Sanjay Patel authored
The motivating case is an infinite loop shown with a reduced test from: https://llvm.org/PR51762 To solve this, I'm proposing we delete the most obviously broken part of this code. The bug example shows a fundamental problem: we ask computeKnownBits if a transform will be profitable, alter the code by creating new instructions, then rely on computeKnownBits to return the same answer to actually eliminate instructions. But there's no guarantee that the results will be the same between the 1st and 2nd calls. In the infinite loop example, we get different answers, so we add instructions that conflict with some other transform, and we're stuck. There's at least one other problem visible in the test diff for `@zext_or_masked_bit_test_uses`: the code doesn't check uses properly, so we can end up with extra instructions created. Last, it's not clear if this set of transforms actually improves analysis or codegen. I spot-checked a few targets and don't see a clear win: https://godbolt.org/z/x87EWovso If we do see a regression from this change, codegen seems like the right place to add a cmp -> bit-hack fold. If this is too big of a step, we could limit the computeKnownBits calls by not passing a context instruction and/or limiting the recursion. I checked that those would stop the infinite loop for PR51762, but that won't guarantee that some other example does not fall into the same loop. Differential Revision: https://reviews.llvm.org/D109440
-
- Sep 08, 2021
-
-
Sanjay Patel authored
-
Sanjay Patel authored
-
- Sep 07, 2021
-
-
Sanjay Patel authored
This could go either direction since the instruction count is the same either way, but there are a few reasons to prefer this: 1. We already do the related transform with 'and' (see just above the new code). 2. We try (too hard) to compensate for not having this and possibly other folds in transformZExtICmp(), and that leads to bugs like https://llvm.org/PR51762 . 3. Codegen looks better across a variety of targets. https://alive2.llvm.org/ce/z/uEgn4P
-
Sanjay Patel authored
-
Nikita Popov authored
Support opaque pointers in SymbolicallyEvaluateGEP() by using the value type of a GlobalValue base or falling back to i8 if there isn't one. We don't unconditionally generate i8 GEPs here because that would lose inrange attribues, and because some optimizations on globals currently rely on GEP types (e.g. the globals SROA mentioned in the comment). Differential Revision: https://reviews.llvm.org/D109297
-
Roman Lebedev authored
Reland "[InstCombine] Recognize `((x * y) s/ x) !=/== y` as an signed multiplication overflow check (PR48769)" This reverts commit 91f7a4ff, relanding commit 13ec913b. The original commit was reverted because of (essentially) https://bugs.llvm.org/show_bug.cgi?id=35922 which has now been addressed by d0eeb64b.
-