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

[Nikita Popov via llvm-commits]

On Sun, Mar 28, 2021 at 8:31 PM Florian Hahn <florian_hahn at apple.com> wrote:

> 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


Thanks for the report! This should be fixed by
https://github.com/llvm/llvm-project/commit/ce066da81c3e6175a02fa7ae831931b5e4126a2b
.

Regards,
Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210328/656f8569/attachment.html>