llvm dev - Sep 2020 - How to clean-up SCEVs from sext/zext/trunc ?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200919/838ab00b/attachment-0001.html>

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>

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>