[llvm-dev] Are SCEV normal form?

Alexandre Isoard via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 11 10:17:11 PDT 2017


Note that there is a slight difficulty due to the fact that we "sink" the
trunc:

(zext i16 {0,+,1}<%bb> to i32) + (65536 * ({0,+,1}<nuw><%bb> /u 65536)

Here the recurrence lost it's <nuw> and got reduced to a i16 (on the left),
but not on the right.

But we can prove:
- that (zext i16 {0,+,1}<%bb> to i32) has the same 16 LSB than (i32
{0,+,1}<nuw><%bb>)
- that (65536 * ({0,+,1}<nuw><%bb> /u 65536) has the same 16 MSB than (i32
{0,+,1}<nuw><%bb>)
And therefore conclude that we can simplify it to (i32 {0,+,1}<nuw><%bb>).

The difficulty is to come up with the (i32 {0,+,1}<nuw><%bb>) in the first
place.

On Fri, Aug 11, 2017 at 5:57 PM, Alexandre Isoard <
alexandre.isoard at gmail.com> wrote:

> Hello again,
>
> On that subject, I have the following SCEV:
>
> (zext i16 (trunc i32 %a to i16) to i32) + ((%a /u 65536) *u 65536)
>
> That I would like to normalize into:
>
> %a
>
> I am not sure where is the most natural spot in which to do that?
> Also, this pattern is much more general. The idea is that I want to
> coalesce bit ranges that have been extracted and put back together.
>
> Should I detect patterns, or look for a more generic strategy? Do you have
> input on that?
>
> On Tue, Jul 25, 2017 at 9:21 PM, Alexandre Isoard <
> alexandre.isoard at gmail.com> wrote:
>
>> Hello,
>>
>> I assumed SCEV purpose was to be a normal form, but then I wondered which
>> one of those is the normal form:
>>
>> (zext i16 (trunc i32 %a to i16) to i32)
>>
>> vs
>>
>> (-((%a /u 65536) *u 65536) + %a)
>>
>>
>> The first one is nice for interval analysis, and known bit analysis.
>> The second one is nice when plugged into gep of 2d arrays.
>>
>> --
>> *Alexandre Isoard*
>>
>
>
>
> --
> *Alexandre Isoard*
>



-- 
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170811/f55f9f2b/attachment.html>


More information about the llvm-dev mailing list