[llvm-dev] How to clean-up SCEVs from sext/zext/trunc ?

Michael Kruse via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 21 11:59:20 PDT 2020


Have you looked into PredicatedScalarEvolution? It can generate
runtime-checks for no-overflow assumptions
(PredicatedScalarEvolution::setNoOverflow).

Michael

Am Fr., 18. Sept. 2020 um 18:13 Uhr schrieb Stefanos Baziotis via llvm-dev <
llvm-dev at lists.llvm.org>:

> Hi everyone,
>
> 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
>
> for (int32_t i ...)
>   for (int32_t j ...)
>   a[i][j] = ...
>
> doesn't work
>
> while this:
>
> for (int64_t i ...)
>   for (int64_t j ...)
>
> does work.
>
> I assume that the former does not work because of sext expressions inside
> the SCEV.
> So, one idea is to clean SCEVs from those and emit run-time checks to
> validate
> that extending 32-bit to 64-bit is ok (if they're needed).
>
> First of all, does that sound reasonable ? Do I miss something ?
>
> Second, what is the best way to clean them ? One possible way is to
> rebuild them (i.e.
> traverse them and build new almost identical expressions, except that we
> ignore the
> problematic instructions). Though I haven't tried it yet.
>
> Thanks,
> Stefanos Baziotis
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200921/b6f30ef5/attachment.html>


More information about the llvm-dev mailing list