[llvm] [InstCombine] Extend folding of aggregate construction to cases when source aggregates are partially available (PR #100828)

[via llvm-commits]

weiguozhi wrote:

I tested it on speccpu 2006 int, this patch is triggerred 19 times for 483.xalancbmk only, but the generated code is same. So no impact.

The real world impact of this patch is to a hot path in tcmalloc. In function _ZN8tcmalloc17tcmalloc_internal14TCMallocPolicyINS0_12CppOomPolicyENS0_18DefaultAlignPolicyENS0_25AllocationAccessHotPolicyENS0_17InvokeHooksPolicyENS0_21IsSizeReturningPolicyENS0_24LocalNumaPartitionPolicyEE10to_pointerEPvmocPolicyINS0_12CppOomPolicyENS0_18DefaultAlignPolicyENS0_25AllocationAccessHotPolicyENS0_17InvokeHooksPolicyENS0_21IsSizeReturningPolicyENS0_24LocalNumaPartitionPolicyEE10to_pointerEPvm (will be inlined into tcmalloc_size_returning_operator_new) there is a code sequence similar to
```
BB1:
   {ptr, i64} %v1 = call {ptr, i64} @func1
   %f1 = extractvalue { ptr, i64 } %v1, 0
   %f2 = extractvalue { ptr, i64 } %v1, 1
   br label %exit

BB2:
   {ptr, i64} %v2 = call {ptr, i64} @_ZN8tcmalloc17tcmalloc_internal14TCMallocPolicyINS0_12CppOomPolicyENS0_18DefaultAlignPolicyENS0_25AllocationAccessHotPolicyENS0_17InvokeHooksPolicyENS0_21IsSizeReturningPolicyENS0_24LocalNumaPartitionPolicyEE10to_pointerEPvmocPolicyINS0_12CppOomPolicyENS0_18DefaultAlignPolicyENS0_25AllocationAccessHotPolicyENS0_17InvokeHooksPolicyENS0_21IsSizeReturningPolicyENS0_24LocalNumaPartitionPolicyEE10to_pointerEPvm 
   %f3 = extractvalue { ptr, i64 } %v2, 0
   %f4 = extractvalue { ptr, i64 } %v2, 1
   br label %exit

exit:
   %f5 = phi ptr [%f1, %BB1], [%f3, %BB2]
   %f6 = phi i64 [%f2, %BB1], [%f4, %BB2]
   %res0 = insertvalue { ptr, i64 } poison, ptr %f5, 0
   %res = insertvalue { ptr, i64 } %res0, i64 %f6, 1
   ret {ptr, i64} %res
```
Usually function foldAggregateConstructionIntoAggregateReuse can optimize away all of the insertvalue/extractvalue,
```
BB1:
   {ptr, i64} %v1 = call {ptr, i64} @func1
   br label %exit

BB2:
   {ptr, i64} %v2 = call {ptr, i64} @_ZN8tcmalloc17tcmalloc_internal14TCMallocPolicyINS0_12CppOomPolicyENS0_18DefaultAlignPolicyENS0_25AllocationAccessHotPolicyENS0_17InvokeHooksPolicyENS0_21IsSizeReturningPolicyENS0_24LocalNumaPartitionPolicyEE10to_pointerEPvmocPolicyINS0_12CppOomPolicyENS0_18DefaultAlignPolicyENS0_25AllocationAccessHotPolicyENS0_17InvokeHooksPolicyENS0_21IsSizeReturningPolicyENS0_24LocalNumaPartitionPolicyEE10to_pointerEPvm 
   br label %exit

exit:
   %res = phi {ptr, i64} [%v1, BB1], [%v2, BB2]
   ret {ptr, i64} %res
```
But in one of our applications built with thinlto, with profile information thinlto causes the function _ZN8tcmalloc17tcmalloc_internal14TCMallocPolicyINS0_12CppOomPolicyENS0_18DefaultAlignPolicyENS0_25AllocationAccessHotPolicyENS0_17InvokeHooksPolicyENS0_21IsSizeReturningPolicyENS0_24LocalNumaPartitionPolicyEE10to_pointerEPvmocPolicyINS0_12CppOomPolicyENS0_18DefaultAlignPolicyENS0_25AllocationAccessHotPolicyENS0_17InvokeHooksPolicyENS0_21IsSizeReturningPolicyENS0_24LocalNumaPartitionPolicyEE10to_pointerEPvm to be inlined, so I got 
```
BB1:
   {ptr, i64} %v1 = call {ptr, i64} @func1
   %f1 = extractvalue { ptr, i64 } %v1, 0
   %f2 = extractvalue { ptr, i64 } %v1, 1
   br label %exit

BB2:
   %f3 = phi ptr [], []
   %f4 = load i64 ...
   br label %exit

exit:
   %f5 = phi ptr [%f1, %BB1], [%f3, %BB2]
   %f6 = phi i64 [%f2, %BB1], [%f4, %BB2]
   %res0 = insertvalue { ptr, i64 } poison, ptr %f5, 0
   %res = insertvalue { ptr, i64 } %res0, i64 %f6, 1
   ret {ptr, i64} %res
```
This instruction sequence can't be handled by the original foldAggregateConstructionIntoAggregateReuse, so worse tcmalloc_size_returning_operator_new was generated.



https://github.com/llvm/llvm-project/pull/100828