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

[Stefanos Baziotis via llvm-dev]

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