llvm dev - Aug 2017 - [ScalarEvolution][SCEV] no-wrap flags dependent on order of getSCEV() calls

Hi,

On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at
codeaurora.org> wrote:
> Oh, I see... yes, we do stupid things involving mutating NoWrap flags after
> a SCEV is created.  (grep for setNoWrapFlags in ScalarEvolution.cpp.)
That's really a compile time hack -- we defer some expensive tricks to
prove nsw/nuw on an add recurrences to when we've been asked to
sign/zero extend said add recurrence.

I would be okay if you wanted to expose those tricks via a helper in
SCEV that could be called independently of creating zero or sign
extensions.  That way SCEV clients could trade-off compile time for
more precise information in a granular way.

-- Sanjoy
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>

On 8/8/2017 8:38 PM, Sanjoy Das wrote:
> Hi,
> 
> On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at
codeaurora.org> wrote:
>> Oh, I see... yes, we do stupid things involving mutating NoWrap flags
after
>> a SCEV is created.  (grep for setNoWrapFlags in ScalarEvolution.cpp.)
> 
> That's really a compile time hack -- we defer some expensive tricks to
> prove nsw/nuw on an add recurrences to when we've been asked to
> sign/zero extend said add recurrence.
If that is the case, preserving SCEV analysis where we didn't before should
only
result in later passes seeing more nsw/nuw flags, which should theoretically be
beneficial?
> I would be okay if you wanted to expose those tricks via a helper in
> SCEV that could be called independently of creating zero or sign
> extensions.  That way SCEV clients could trade-off compile time for>
more precise information in a granular way.
I'm not concerned with getting better SCEV results at the moment, I just
want to
make sure that changing these passes to preserve SCEV analysis is behaving as
expected (which it sounds like it is).
> 
> -- Sanjoy
> 
>>
>> -Eli
>>
>> --
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux
>> Foundation Collaborative Project
>>
-- 
Geoff Berry
Employee of Qualcomm Datacenter Technologies, Inc.
  Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.

Hi Geoff,

On Wed, Aug 9, 2017 at 8:58 AM, Geoff Berry <gberry at codeaurora.org>
wrote:
> On 8/8/2017 8:38 PM, Sanjoy Das wrote:
>>
>> Hi,
>>
>> On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at
codeaurora.org>
>> wrote:
>>>
>>> Oh, I see... yes, we do stupid things involving mutating NoWrap
flags
>>> after
>>> a SCEV is created.  (grep for setNoWrapFlags in
ScalarEvolution.cpp.)
>>
>>
>> That's really a compile time hack -- we defer some expensive tricks
to
>> prove nsw/nuw on an add recurrences to when we've been asked to
>> sign/zero extend said add recurrence.
>
>
> If that is the case, preserving SCEV analysis where we didn't before
should
> only
> result in later passes seeing more nsw/nuw flags, which should
theoretically
> be
> beneficial?
There are downsides to preserving SCEV for "too long" though -- if you
simplified a loop in a way that SCEV can compute its trip count when
it couldn't before (or it could compute a trip count before, but now
it can compute a more precise trip count) then invalidating the cache
can be an improvement.  However, in this case judicious use of
forgetLoop() (as opposed to re-constructing the whole of SCEV) will
also do the job.

-- Sanjoy
>> I would be okay if you wanted to expose those tricks via a helper in
>> SCEV that could be called independently of creating zero or sign
>> extensions.  That way SCEV clients could trade-off compile time for>
more
>> precise information in a granular way.
>
>
> I'm not concerned with getting better SCEV results at the moment, I
just
> want to
> make sure that changing these passes to preserve SCEV analysis is behaving
> as
> expected (which it sounds like it is).
>
>>
>> -- Sanjoy
>>
>>>
>>> -Eli
>>>
>>> --
>>> Employee of Qualcomm Innovation Center, Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a
>>> Linux
>>> Foundation Collaborative Project
>>>
>
> --
> Geoff Berry
> Employee of Qualcomm Datacenter Technologies, Inc.
>  Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the Code
> Aurora Forum, a Linux Foundation Collaborative Project.