[llvm-dev] IndVarSimplify: getBackedgeTakenCount and Release vs Assert

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 18 14:31:58 PST 2020


I wish this was entirely true.  The are known issues in SCEV where the 
order in which queries are performed can influence which set of results 
get cached.  As such, you can get two equally valid and correct answers 
with different levels of precision by simply changing the order in which 
you ask queries.  I suspect that's what is going on here.  I agree that 
it's very unfortunate, but I don't think it's easy to fix either.

Philip

On 2/5/20 1:02 PM, Michael Kruse wrote:
> This is definitely not expected. `getBackedgeTakenCount` caches some
> intermediate results (e.g. SCEV normalized forms) and its not unheard
> of that these influence other computations. However, the results
> should be the same whether its from the cache of freshly computed. It
> is also possible that some pass does not correctly invalidate a
> result.
>
> Could you file a bug?
>
> Michael
>
> Am Mi., 5. Feb. 2020 um 11:46 Uhr schrieb Jeroen Dobbelaere via
> llvm-dev <llvm-dev at lists.llvm.org>:
>> Hi,
>>
>> I am investigating a difference in code generation between release and assert builds of llvm.
>> The culprit is IndVarSimplify that comes up with different behavior on the same input:
>>   in the assertion build, it does do an extra 'INDVARS: Rewriting loop exit condition'
>>
>> After digging around, it seems that following change is the culprit:
>>
>> -----
>> Author: Philip Reames <listmail at philipreames.com>  2019-08-01 03:16:08
>> Committer: Philip Reames <listmail at philipreames.com>  2019-08-01 03:16:08
>>
>>      Fix a release-only build warning triggered by rL367485
>>
>>      llvm-svn: 367499
>>
>>
>> [..]
>>
>>
>> +#ifndef NDEBUG
>> +  // Used below for a consistency check only
>>     const SCEV *BackedgeTakenCount = SE->getBackedgeTakenCount(L);
>> +#endif
>> -----
>>
>> It seems that the 'SE->getBackedgeTakenCount(L)' call has sideeffects.. Is that to be expected ?
>> Is the correct solution then to always keep the call ?
>>
>> Thanks,
>>
>> Jeroen Dobbelaere
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list