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

[Michael Kruse via llvm-dev]

Yes, there is PredicatedScalarEvolution::getSCEV that rewrites SCEVs using
collected predicates.

Michael

Am Mo., 21. Sept. 2020 um 14:55 Uhr schrieb Stefanos Baziotis <
stefanos.baziotis at gmail.com>:

> Hi Michael,
>
> Thanks for the reply. I've seen but have not used it. FWIW, the problem is
> not how to generate the runtime
> checks (although it'd be good if we can get it for free), but how to clean
> up the SCEVs. Does PSE do that ?
>
> Cheers,
> Stefanos
>
> Στις Δευ, 21 Σεπ 2020 στις 11:59 π.μ., ο/η Michael Kruse <
> llvmdev at meinersbur.de> έγραψε:
>
>> 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/056906ba/attachment.html>