Not sure if I'm using it correctly, but the online instance of Alive2 does not show this as invalid?
http://volta.cs.utah.edu:8080/z/UutRJe

The quick fix:

diff --git a/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp b/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
index 63bf3462faa..c4d7a956025 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
@@ -159,7 +159,7 @@ Instruction *InstCombiner::foldCmpLoadFromIndexedGlobal(GetElementPtrInst *GEP,
// the simple index into a single-dimensional array.
//
// Require: GEP GV, 0, i {{, constant indices}}

• if (GEP->getNumOperands() < 3 ||

• if (!GEP->isInBounds() || GEP->getNumOperands() < 3 ||
  !isa(GEP->getOperand(1)) ||
  !cast(GEP->getOperand(1))->isZero() ||
  isa(GEP->getOperand(2)))

But that causes 5 other test changes (no more optimization) in that same regression test file.

I think the tests were meant to exercise various possibilities for that index variable such as "what if its size is too small to cause an overflow?"

That is, do we need to use the datalayout in addition to 'inbounds' to decide how to limit this transform?

Not sure if I'm using it correctly, but the online instance of Alive2 does
not show this as invalid?
http://volta.cs.utah.edu:8080/z/UutRJe

You're doing it right; I just think the online version is a bit old.
John, could you check please?

I just updated both LLVM and Alive2. The example is still reading as correct, and I have made sure I'm not seeing cached results.

That is, do we need to use the datalayout in addition to 'inbounds' to
decide how to limit this transform?

For the given testcase, we only produce the wrong result for precisely x == 0x80000009. We could mask off the high bit to produce the correct result, I think. The general form of the transform is something like "(x & (-1 >> TrailingBits(sizeof(IndexedType)))) == n".

I could reproduce this with 64 bits offset:
http://volta.cs.utah.edu:8080/z/x-9fib

Alive2 says the offset can be truncated and compared as well:
http://volta.cs.utah.edu:8080/z/3ABHi3

Right, both the target data & sizeof(type) are important because the bug is triggered as Eli say when sext(idx) * sizeof(type) overflows.

It seems there's a bug in Alive2 and/or the online tool ATM, sorry. We are looking into it. The example I posted is valid though.

Alive2 + CE problem was my fault. Should be fixed now, sorry about that.

Alive2 link: https://alive2.llvm.org/ce/z/bGG9Vy

Fixed: https://reviews.llvm.org/D99481