scalarrepl doesn't promote alloca in 2008-03-24-BitField-And-Alloca.c

[lattner]

Bugzilla Link	3290
Resolution	FIXED
Resolved on	Jan 08, 2009 23:47
Version	1.0
OS	All
Blocks	#3604
Attachments	testcase, another related testcase

Extended Description

This is split off from bug 3232, where we learned that diabling gcc's inliner caused a perf regression in 2008-03-24-BitField-And-Alloca.c because scalarrepl isn't promoting the allocas anymore.

This in turn is because of how the struct is being passed by value to a function: due to the ABI lowering stuff in the front-end, it is passed as an i64, so we get this code, which confuses scalarrepl:

%struct.Key = type { { i32, i32 } }

...
%iospec = alloca %struct.Key ; <%struct.Key*> [#uses=3]
...
%2 = bitcast %struct.Key* %iospec to i64* ; <i64*> [#uses=1]
store i64 %key_token2, i64* %2, align 8

Perhaps scalarrepl can handle this the same way it handles memcpy.

[lattner]

First patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090105/071859.html

[lattner]

Second half of the sroa change here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090105/071894.html

[lattner]

The iospec struct is now getting promoted, but iospec2 isn't. iospec2 is not getting promoted because of this craziness:

%struct.Key = type { { i32, i32 } }
%struct.anon = type <{ i8, [3 x i8], i32 }>

...
%iospec2 = alloca %struct.Key, align 8 ; <%struct.Key*> [#uses=3]
...
%3 = bitcast %struct.Key* %iospec2 to %struct.anon* ; <%struct.anon*> [#uses=1]
%4 = getelementptr %struct.anon* %3, i32 0, i32 2 ; <i32*> [#uses=1]
%5 = load i32* %4, align 4 ; [#uses=3]

I guess I could make instcombine zap the bitcast+gep, replacing it with "gep %3, 0, 0, 1", but why isn't llvm-gcc generating this in the first place? Duncan do you have any idea? Is fixing instcombine really the preferable approach?

[llvmbot]

    %struct.anon = type <{ i8, [3 x i8], i32 }>

I took a quick look a while ago, and if I recall correctly
it was because of this field:

unsigned int AType : 4;

This spans bits 13-16. The fact that it spills over
the edge of a byte boundary triggered some logic in
the struct conversion stuff (again, IIRC). I've added
Devang to the CC list because maybe he wrote this code.

[lattner]

I think this is a specific case of a general problem with SROA of structs containing unions. Accesses to one side of the union or the other will cause a bitcast of the pointer, preventing the SROA from happening.

[lattner]

Part 3 is implemented here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090105/071949.html

This test is now passing, reenabled here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090105/071950.html

-Chris