Modifying function and parameter types during optimization

[carsonharmon]

While working on the pointer lifter Peter gave me a test that brought up an interesting case.

BitCasts can give more information about intended types, lets look at this example 

; Function Attrs: noinline
define i64 @valid_test(i64* %0) local_unnamed_addr #1 {
  %2 = bitcast i64* %0 to i8**
  %3 = load i8*, i8** %2, align 8
  %4 = getelementptr i8, i8* %3, i64 36
  %5 = bitcast i8* %4 to i32*
  %6 = load i32, i32* %5, align 4
  %7 = zext i32 %6 to i64
  ret i64 %7
}


After propagating first bitcast it should be 
; Function Attrs: noinline
define i64 @valid_test(i8** %0) local_unnamed_addr #1 {
  %3 = load i8*, i8** %0, align 8
  %4 = getelementptr i8, i8* %3, i64 36
  %5 = bitcast i8* %4 to i32*
  %6 = load i32, i32* %5, align 4
  %7 = zext i32 %6 to i64
  ret i64 %7
}

After second bitcast. 

; Function Attrs: noinline
define i64 @valid_test(i32** %0) local_unnamed_addr #1 {
  %3 = load i32*, i32** %0, align 8
  %4 = getelementptr i32, i32* %3, i32 9
  %6 = load i32, i32* %4, align 4
  %7 = zext i32 %6 to i64
  ret i64 %7
}

In order to make this transformation without breaking code, we would have to update the type of the function parameter %0. I'm not sure that the pointer lifter should do this, because it means we would need to find all the other call sites of this function and bitcast the parameters being passed.

On the bright side, if that parameter is in fact a pointer type, then we have just seeded more functions with pointer information we can use in the next optimization round.

Oh and another thing, the return types for this function should be i32 anyway, the C code just returns an int. So we could also remove the extension before the return, if we could safely make that assumption.

Peter also has some ideas related to a reporting system, I will summon @pgoodman to add on his thoughts.