<div dir="ltr">Have you looked into PredicatedScalarEvolution? It can generate runtime-checks for no-overflow assumptions (PredicatedScalarEvolution::setNoOverflow).<div><br></div><div>Michael</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 18. Sept. 2020 um 18:13 Uhr schrieb Stefanos Baziotis via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone,<br><br>I've been using SCEV Delinearization but it fails when other-than-pointer-size values are used in the subscripts. To make that clear, say that we have a target in which pointers are 64-bit<br><br>for (int32_t i ...)<br>  for (int32_t j ...)<br>  a[i][j] = ...<br><br>doesn't work<br><br>while this:<br><br>for (int64_t i ...)<br>  for (int64_t j ...)<br><br>does work.<br><br>I assume that the former does not work because of sext expressions inside the SCEV.<br>So, one idea is to clean SCEVs from those and emit run-time checks to validate<br>that extending 32-bit to 64-bit is ok (if they're needed).<br><br>First of all, does that sound reasonable ? Do I miss something ?<br><br>Second, what is the best way to clean them ? One possible way is to rebuild them (i.e.<br>traverse them and build new almost identical expressions, except that we ignore the<br>problematic instructions). Though I haven't tried it yet.<br><br>Thanks,<br>Stefanos Baziotis</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>