[llvm] r374535 - [SCEV] Add stricter verification option.

[Philip Reames via llvm-commits]

A late response for a late response....

Your points make sense to me.  I'm not sure I'd actually use a "too 
strict" verifiier (i.e. one with known false positives), but if you want 
it and it's commented appropriately, I certainly don't object.

Philip

On 10/16/19 10:49 PM, Florian Hahn wrote:
>
>> On Oct 11, 2019, at 17:35, Philip Reames via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>>
>> I may be missing the obvious, but why is a symbolic expression which *may* be zero a violation here?  It would seem to be a missed canonicalization, nothing more.
>>
> Sorry for the late reply, I unfortunately missed your meal while I was traveling.
>
> My intention here was primary to add a very strict option to surface more potential inconsistencies, as there seem to have surfaced a few issues recently that are related to SCEV expressions not being properly invalidated. It is overly strict, but I think it could be helpful in tracking down some cases we miss at the moment and we would have to evaluate the issues on a case-by-case basis.
>
>> I agree that a SCEV which is known (via isKnownPredicate?) not to be zero is a bug.
> I think using isKnownPredicate to check if the delta is zero is something we should do even for the normal -verify-scev option, as it slightly strengthens the check, closing the gap between the overly strict one. My initial builds of test-suite and LLVM bootstrapping seemed to pass when using isKnownPredicate. I would be happy to put up a patch in that direction.
>
> Cheers,
> Florian