[llvm] 9075864 - [BasicAA] Refactor linear expression decomposition

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Sun Mar 28 11:31:48 PDT 2021


Hi,

> On Mar 27, 2021, at 22:32, Nikita Popov via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> 
> Author: Nikita Popov
> Date: 2021-03-27T23:31:58+01:00
> New Revision: 9075864b7375b4eb8f2c0663caa575c0c667de7c
> 
> URL: https://github.com/llvm/llvm-project/commit/9075864b7375b4eb8f2c0663caa575c0c667de7c
> DIFF: https://github.com/llvm/llvm-project/commit/9075864b7375b4eb8f2c0663caa575c0c667de7c.diff
> 
> LOG: [BasicAA] Refactor linear expression decomposition
> 
> The current linear expression decomposition handles zext/sext by
> decomposing the casted operand, and then checking NUW/NSW flags
> to determine whether the extension can be distributed. This has
> some disadvantages:
> 
> First, it is not possible to perform a partial decomposition. If
> we have zext((x + C1) +<nuw> C2) then we will fail to decompose
> the expression entirely, even though it would be safe and
> profitable to decompose it to zext(x + C1) +<nuw> zext(C2)
> 
> Second, we may end up performing unnecessary decompositions,
> which will later be discarded because they lack nowrap flags
> necessary for extensions.
> 
> Third, correctness of the code is not entirely obvious: At a high
> level, we encounter zext(x -<nuw> C) in the form of a zext on the
> linear expression x + (-C) with nuw flag set. Notably, this case
> must be treated as zext(x) + -zext(C) rather than zext(x) + zext(-C).
> The code handles this correctly by speculatively zexting constants
> to the final bitwidth, and performing additional fixup if the
> actual extension turns out to be an sext. This was not immediately
> obvious to me.
> 
> This patch inverts the approach: An ExtendedValue represents a
> zext(sext(V)), and linear expression decomposition will try to
> decompose V further, either by absorbing another sext/zext into the
> ExtendedValue, or by distributing zext(sext(x op C)) over a binary
> operator with appropriate nsw/nuw flags. At each step we can
> determine whether distribution is legal and abort with a partial
> decomposition if not. We also know which extensions we need to
> apply to constants, and don't need to speculate or fixup.
> 


This appears to be causing the following failure: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32621

Cheers,
Florian


More information about the llvm-commits mailing list