[llvm-commits] [llvm] r153419 - in /llvm/trunk: lib/Analysis/InstructionSimplify.cpp test/Transforms/InstSimplify/compare.ll

[Jay Foad]

On 28 March 2012 12:23, Jay Foad <jay.foad at gmail.com> wrote:
> Hi Chandler,
>
> On 26 March 2012 11:26, Duncan Sands <baldrick at free.fr> wrote:
>>> +  case CmpInst::ICMP_EQ:
>>> +  case CmpInst::ICMP_NE:
>>> +    break;
>>> +
>>> +    // We can only handle unsigned relational comparisons because 'inbounds' on
>>> +    // a GEP only protects against unsigned wrapping.
>>> +  case CmpInst::ICMP_UGT:
>>> +  case CmpInst::ICMP_UGE:
>>> +  case CmpInst::ICMP_ULT:
>>> +  case CmpInst::ICMP_ULE:
>>> +    // However, we have to switch them to their signed variants to handle
>>> +    // negative indices from the base pointer.
>>> +    Pred = ICmpInst::getSignedPredicate(Pred);
>>
>> Is this correct?  For example, suppose the base pointer is null (otherwise
>> known as 0), LHSOffset is 2^31-1, RHSOffset is 2^31, and you are doing a
>> unsigned < comparison.  The result should be true, but you will return false.
>
> Duncan's analysis seems right to me. Is there some guarantee that
> objects are smaller than half the address space? If not, this
> optimisation seems broken.

Here's a C testcase (running on Linux/x86_64):

$ cat o.c
extern char a[3000000000U];

static int f(char *p) {
  return &p[0] < &p[sizeof a];
}

int main() {
  return f(a);
}
$ clang -m32 -O -o o o.c && ./o ; echo $?
0

But gcc -m32 complains:

o.c:1:13: error: size of array ‘a’ is too large

so maybe we should be restricting the size of objects?

Jay.