Support inbounds GEP in LLVM constant expressions about crucible

[robdockins]

What code gets LLVM to produce the inrange flag? I was never sure how to trigger it last time I looked at this.

[atomb]

I'm not entirely sure. The file that triggers this is about 1MB of LLVM bitcode from some modern-style C++ source.

[robdockins]

For now, I've modified the constant expression translation code to ignore the inrange flag. This is not completely sound, but allows us to accept more code.

To correctly address this issue would take some additional nontrivial infrastructure to add artificial bounds to pointer values, beyond those corresponding to the bounds of memory objects.

[acfoltzer]

FWIW, I believe this is why this verification is failing: https://github.com/acfoltzer/charm/blob/O2-gep-bug/verify/verify-xoodoo.sh

The default and -O1 versions work fine, but when I try to run -O2 bitcode it produces:

Invalid GEP
getelementptr inbounds <16 x i8>, <16 x i8>* %8, i64 0, i64 0

[robdockins]

Oh, that's a pretty odd construct... I can see why we reject it, it doesn't make a lot of sense. Looks like a clang bug to me; either that, or I've misunderstood something about GEPs (always a possibility).

At any rate, I don't think it's related to the inrange flag.

[acfoltzer]

Ah, right, it's still early enough for me to mix up inrange and inbounds.

[robdockins]

Is it reasonable for you to produce a complete bitcode file of the example that's causing problems? I find these things are often quite sensitive to the exact compiler and build environment.