[all-commits] [llvm/llvm-project] 311779: [NFCI][IR] ConstantRangeTest: refactor operation r...

[Roman Lebedev via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 31177949cb1d88d7dd32078d09a265b828d40826
      https://github.com/llvm/llvm-project/commit/31177949cb1d88d7dd32078d09a265b828d40826
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-09-25 (Fri, 25 Sep 2020)

  Changed paths:
    M llvm/unittests/IR/ConstantRangeTest.cpp

  Log Message:
  -----------
  [NFCI][IR] ConstantRangeTest: refactor operation range gatherers

We do the same dance to acquire the "exact" range of an op via
an exhaustive approach in many places.
Let's not invent the wheel each time.


  Commit: 9bcf7b1c7a139a455400df109d81c638b9e75150
      https://github.com/llvm/llvm-project/commit/9bcf7b1c7a139a455400df109d81c638b9e75150
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-09-25 (Fri, 25 Sep 2020)

  Changed paths:
    M llvm/unittests/IR/ConstantRangeTest.cpp

  Log Message:
  -----------
  [NFCI][IR] ConstantRangeTest: add basic scaffolding for next-gen precision/correctness testing

I have long complained that while we have exhaustive tests
for ConstantRange, they are, uh, not good.

The approach of groking our own constant range
via exhaustive enumeration is, mysterious.

It neither tells us without doubt that the result is
conservatively correct, nor the precise match to the ConstantRange
result tells us that the result is precise.
But yeah, it's fast, i give it that.

In short, there are three things that we need to check:
1. That ConstantRange result is conservatively correct
2. That ConstantRange range is reasonable
3. That ConstantRange result is reasonably precise

So let's not just check the middle one, but all three.

This provides precision test coverage for D88178.


Compare: https://github.com/llvm/llvm-project/compare/0c0c57f7b21b...9bcf7b1c7a13