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

[Stefanos Baziotis via llvm-dev]

Great thanks.

- Stefanos

Στις Δευ, 21 Σεπ 2020 στις 12:57 μ.μ., ο/η Michael Kruse <
llvmdev at meinersbur.de> έγραψε:

> 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/9c0350e0/attachment.html>