search for: isgepbaseatnegativeoffset

...ementptr inbounds ([2147483656 x i8], [2147483656 x i8]* @obj, i32 0, i32 0), i32 -2147483648), align 1 ret i8 %1 } With -O2, the store to q gets forwarded, and so we get "ret i8 1". So, BasicAA concluded that p and q don't alias. The culprit is an overflow in BasicAAResult::isGEPBaseAtNegativeOffset(). So my question is do we care about this use case where a single allocation can take more than half of the address space? Thanks, Nuno

...@obj, i32 0, i32 0), >> i32 -2147483648), align 1 >> ret i8 %1 >> } >> >> With -O2, the store to q gets forwarded, and so we get "ret i8 1". >> So, BasicAA concluded that p and q don't alias. The culprit is an >> overflow in BasicAAResult::isGEPBaseAtNegativeOffset(). >> >> So my question is do we care about this use case where a single >> allocation can take more than half of the address space? >> >> Thanks, >> Nuno

...@obj, i32 0, i32 0), >> i32 -2147483648), align 1 >> ret i8 %1 >> } >> >> With -O2, the store to q gets forwarded, and so we get "ret i8 1". >> So, BasicAA concluded that p and q don't alias. The culprit is an >> overflow in BasicAAResult::isGEPBaseAtNegativeOffset(). >> >> So my question is do we care about this use case where a single >> allocation can take more than half of the address space? >> > > Accoding to LangRef, your IR currently has undefined behavior: the rules > for "inbounds" GEPs say that indexes ar...