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>