Missed store-load forwarding due to asymmetric alias information

[dobbelaj-snps]

Bugzilla Link	39186
Version	trunk
OS	Windows NT
Attachments	test.c showing two similar cases, one that gets optimized, one that doesn't
CC	@hfinkel

Extended Description

The attached testcase results in following asymmetric alias relationship between two stores and one load.
(A) store 42, %0
(B) store 43, %1
(C) load %0

for FOO:
(A)-(B): may alias
(A)-(C): must alias
(B)-(C): no alias (due to __restrict)

for BAR:
(A)-(B): no alias (due to __restrict)
(A)-(C): must alias
(B)-(C): may alias

Content after inlining:

case 'FOO':
*** IR Dump After Function Integration/Inlining ***
; Function Attrs: nounwind uwtable
define dso_local i32 @​foo(i32*, i32*) local_unnamed_addr #​0 {
store i32 42, i32* %0, align 4, !tbaa !​2
store i32 43, i32* %1, align 4, !tbaa !​2, !noalias !​6
%3 = load i32, i32* %0, align 4, !tbaa !​2, !alias.scope !​6
ret i32 %3
}

case 'BAR':
*** IR Dump After Function Integration/Inlining ***
; Function Attrs: nounwind uwtable
define dso_local i32 @​bar(i32*, i32*) local_unnamed_addr #​2 {
store i32 42, i32* %0, align 4, !tbaa !​2, !alias.scope !​6
store i32 43, i32* %1, align 4, !tbaa !​2, !noalias !​6
%3 = load i32, i32* %0, align 4, !tbaa !​2
ret i32 %3
}

• EarlyCSE is able to optimize foo and see that the load is not necessary.
• EarlyCSE, GVN and NewGVN are not able to optimize bar.

NOTE: gcc is able to optimize both cases