missed reassociate due to GEP

[nlewycky]

Bugzilla Link	11412
Version	trunk
OS	Linux
CC	@efriedma-quic,@zygoloid

Extended Description

This is a copy of part of std::vector's _M_insert_aux, the function that causes v.push_back(4) to not get inlined.

define i8* @​test(i8* %ptr, i8* %ptr2) {
%A = getelementptr inbounds i8* %ptr, i64 -1

%B = ptrtoint i8* %A to i64
%C = ptrtoint i8* %ptr2 to i64
%D1 = sub i64 %C, %B
%F = getelementptr inbounds i8* %ptr, i64 %D1

ret i8* %F

}

If we prevent instcombine from forming overflow intrinsics (no PR# but those block us from getting this far), we get the above sequence. Stop me if I'm wrong but that's:

%F = ptr + ( (ptr2) - (ptr - 1) )
= ptr + ptr2 - ptr + 1
= ptr2 + 1
= getelementptr inbounds i8* %ptr2, i64 1

Probably instcombine should go get that, maybe reassociate.

[efriedma-quic]

If you replace the subtraction with real inbounds pointer subtraction, yes, those are all equivalent. The transformation isn't safe as given, though, because we can't prove %ptr and %ptr2 point into the same object.

[nlewycky]

If I understand you correctly, we can still produce "GEP %ptr2, 1" but without the inbounds marker? I'm not clear at all on why %ptr and %ptr2 would need to point into the same object (I've been assuming they don't)?

[efriedma-quic]

If I understand you correctly, we can still produce "GEP %ptr2, 1" but without
the inbounds marker?

No, you'd have to use integer math and convert the result with inttoptr; your transformation replaces a pointer based on %ptr with a pointer based on %ptr2.

I'm not clear at all on why %ptr and %ptr2 would need to
point into the same object (I've been assuming they don't)?

I'm assuming in the context of push_back the two pointers both point to elements of the same array. We can't prove that in the given IR, though.