constant folding should fold this constant expr

[lattner]

Bugzilla Link	3351
Resolution	FIXED
Resolved on	Jan 01, 2010 19:23
Version	1.0
OS	All
CC	@efriedma-quic,@nlewycky

Extended Description

483.xalancbmk retains this awesome constant expr until codegen:

%0 = load i16* getelementptr ([7 x i16]* @&#8203;_ZN11xercesc_2_5L17gIdeographicCharsE, i32 0, i32 add (i32 ashr (i32 sub (i32 ptrtoint (i16* getelementptr ([7 x i16]* @&#8203;_ZN11xercesc_2_5L17gIdeographicCharsE, i32 0, i32 4) to i32), i32 ptrtoint ([7 x i16]* @&#8203;_ZN11xercesc_2_5L17gIdeographicCharsE to i32)), i32 1), i32 1)), align 4		; <i16> [#uses=0]

This should get folded at the sub.

[llvmbot]

It would be helpful to have a testcase that can be bunged directly
into opt rather than this snippet.

[efriedma-quic]

C code:
int a[10]; int b() { return a[&a[4]-&a[2]]; }

LLVM IL:
@​a = common global [10 x i32] zeroinitializer, align 4

define i32 @​b() nounwind readonly {
entry:
%tmp = load i32* getelementptr ([10 x i32]* @​a, i32 0, i32 ashr (i32 sub (i32 ptrtoint (i32* getelementptr ([10 x i32]* @​a, i32 0, i32 4) to i32), i32 ptrtoint (i32* getelementptr ([10 x i32]* @​a, i32 0, i32 2) to i32)), i32 2))
ret i32 %tmp
}

[lattner]

Xerces doesn't have this one anymore (at least at -m64, have to check -m32 still), but it does still have this one idiom several times:

i1 icmp eq (i64 or
(i64 ptrtoint ([33 x i16]* @​_ZN11xercesc_2_513SchemaSymbols21fgURI_SCHEMAFORSCHEMAE to i64),
i64 ptrtoint ([7 x i16]* @​_ZN11xercesc_2 _513SchemaSymbols11fgDT_STRINGE to i64)),
i64 0)

Two pointers or'd together != 0.

[lattner]

Verified, that issue is gone in 32-bit as well. Here's another amusing constantexpr issue from this benchmark:

%__first_addr.0.i.i = getelementptr [12 x i16]* @​_ZN10xalanc_1_827XalanEXSLTFunctionEncodeURI15s_reservedCharsE, i64 0, i64 %tmp
...

%160 = ptrtoint i16* %__first_addr.0.i.i to i64
%161 = sub nsw i64 ptrtoint (i16* getelementptr inbounds ([12 x i16]* @​_ZN10xalanc_1_827XalanEXSLTFunctionEncodeURI15s_reservedCharsE, i64 1, i64 0) to i64
), %160

%162 = ashr i64 %161, 1
...

which is yet-another pointer difference case.

[lattner]

The 'or' idiom also comes up in non-constant expr cases as well. I'm going to dig in to find out wtf causes this:

%11 = ptrtoint i16* %name to i64 ; [#uses=1]
%12 = or i64 %11, ptrtoint ([33 x i16]* @​_ZN11xercesc_2_513SchemaSymbols21fgURI_SCHEMAFORSCHEMAE to i64) ; [#uses=1]
%13 = inttoptr i64 %12 to i16* ; <i16*> [#uses=1]
%14 = icmp eq i16* %13, null ; [#uses=1]
br i1 %14, label %bb8, label %bb2

[lattner]

Ah, the 'or' issue comes from this:

inline bool XMLString::equals( const XMLCh* const str1
, const XMLCh* const str2)
{
if (str1 == 0 || str2 == 0) {

This is the dubious instcombine that turns two icmp eq's of pointers into the ptrtoint+or series.

[lattner]

Comment #​4 addressed with these patches:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091228/093351.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091228/093352.html

[lattner]

The 'or' issue is fixed by these patch, which move the xform from instcombine to codegen:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091228/093356.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091228/093358.html

483.xalancbmk still has instances of this because GCC's fold routine in llvm-gcc is doing the same xform as instcombine was.

[lattner]

This kills off the constantexprs for llvm-gcc:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091228/093359.html