<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 28, 2021 at 8:31 PM Florian Hahn <<a href="mailto:florian_hahn@apple.com">florian_hahn@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
> On Mar 27, 2021, at 22:32, Nikita Popov via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
> <br>
> <br>
> Author: Nikita Popov<br>
> Date: 2021-03-27T23:31:58+01:00<br>
> New Revision: 9075864b7375b4eb8f2c0663caa575c0c667de7c<br>
> <br>
> URL: <a href="https://github.com/llvm/llvm-project/commit/9075864b7375b4eb8f2c0663caa575c0c667de7c" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/commit/9075864b7375b4eb8f2c0663caa575c0c667de7c</a><br>
> DIFF: <a href="https://github.com/llvm/llvm-project/commit/9075864b7375b4eb8f2c0663caa575c0c667de7c.diff" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/commit/9075864b7375b4eb8f2c0663caa575c0c667de7c.diff</a><br>
> <br>
> LOG: [BasicAA] Refactor linear expression decomposition<br>
> <br>
> The current linear expression decomposition handles zext/sext by<br>
> decomposing the casted operand, and then checking NUW/NSW flags<br>
> to determine whether the extension can be distributed. This has<br>
> some disadvantages:<br>
> <br>
> First, it is not possible to perform a partial decomposition. If<br>
> we have zext((x + C1) +<nuw> C2) then we will fail to decompose<br>
> the expression entirely, even though it would be safe and<br>
> profitable to decompose it to zext(x + C1) +<nuw> zext(C2)<br>
> <br>
> Second, we may end up performing unnecessary decompositions,<br>
> which will later be discarded because they lack nowrap flags<br>
> necessary for extensions.<br>
> <br>
> Third, correctness of the code is not entirely obvious: At a high<br>
> level, we encounter zext(x -<nuw> C) in the form of a zext on the<br>
> linear expression x + (-C) with nuw flag set. Notably, this case<br>
> must be treated as zext(x) + -zext(C) rather than zext(x) + zext(-C).<br>
> The code handles this correctly by speculatively zexting constants<br>
> to the final bitwidth, and performing additional fixup if the<br>
> actual extension turns out to be an sext. This was not immediately<br>
> obvious to me.<br>
> <br>
> This patch inverts the approach: An ExtendedValue represents a<br>
> zext(sext(V)), and linear expression decomposition will try to<br>
> decompose V further, either by absorbing another sext/zext into the<br>
> ExtendedValue, or by distributing zext(sext(x op C)) over a binary<br>
> operator with appropriate nsw/nuw flags. At each step we can<br>
> determine whether distribution is legal and abort with a partial<br>
> decomposition if not. We also know which extensions we need to<br>
> apply to constants, and don't need to speculate or fixup.<br>
> <br>
<br>
<br>
This appears to be causing the following failure: <a href="https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32621" rel="noreferrer" target="_blank">https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32621</a></blockquote><div><br></div><div>Thanks for the report! This should be fixed by <a href="https://github.com/llvm/llvm-project/commit/ce066da81c3e6175a02fa7ae831931b5e4126a2b">https://github.com/llvm/llvm-project/commit/ce066da81c3e6175a02fa7ae831931b5e4126a2b</a>.</div><div><br></div><div>Regards,<br></div><div>Nikita<br> </div></div></div>