<div dir="ltr">Ok, thanks. I'll try to come up with a more generic test case. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 14, 2021 at 2:00 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com">johannesdoerfert@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nothing comes to mind given the information.<br>
<br>
~ Johannes<br>
<br>
<br>
On 1/14/21 12:56 PM, Ryan Taylor wrote:<br>
> argmemonly, nounwind, writeonly<br>
><br>
> -fno-strict-aliasing did not help.<br>
><br>
> On Thu, Jan 14, 2021 at 1:29 PM Johannes Doerfert <<br>
> <a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> wrote:<br>
><br>
>> Can you share the attributes of the intrinsic declaration,<br>
>> assuming removing `!tbaa` didn't help.<br>
>><br>
>><br>
>> On 1/14/21 11:43 AM, Ryan Taylor wrote:<br>
>>> Yes, this is for downstream/out of tree target so I'm not sure how you<br>
>>> could reproduce it either but I thought the IR might help a bit.<br>
>>><br>
>>> My guess is it's not a bug in GVN as much as an issue with the intrinsic<br>
>>> properties, or lack thereof. I put this in the first post but the Alias<br>
>>> Sets show:<br>
>>><br>
>>> AliasSet[0x75fbd0, 9] may alias, Mod/Ref Pointers: (i8* %1, 8), (i16*<br>
>>> %arrayidx, 2), (i16* %arrayidx1, 2), (i16* %arrayidx5, 2), (i16* %19, 2),<br>
>>> (i16* %arrayidx6, 2), (i16* %arrayidx14, 2), (i16* %arrayidx19, 2)<br>
>>> 4 Unknown instructions: void <badref>, <4 x i16>* %6, <4 x i16>*<br>
>> %22,<br>
>>> void <badref><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Jan 14, 2021 at 12:37 PM Johannes Doerfert <<br>
>>> <a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> wrote:<br>
>>><br>
>>>> There is still not enough information here.<br>
>>>><br>
>>>> My first guess. The `!tbaa` annotation on the `XXX.intrinsic` and the<br>
>>>> `load`<br>
>>>> basically encode there is no alias. Easy to verify, remove the ones on<br>
>> the<br>
>>>> intrinsic.<br>
>>>><br>
>>>> ~ Johannes<br>
>>>><br>
>>>><br>
>>>> P.S. If this was a bug in GVN, and I assume it is not, a reproducer<br>
>>>> would help<br>
>>>> a lot. So a small IR sample that shows the problem and which we<br>
>>>> can run.<br>
>>>> This is a "redacted?" IR fragment in which I don't know what<br>
>>>> transformation<br>
>>>> is problematic. I also can not run it through GVN, which makes it<br>
>>>> impossible<br>
>>>> to reproduce.<br>
>>>><br>
>>>><br>
>>>> On 1/14/21 11:27 AM, Ryan Taylor via llvm-dev wrote:<br>
>>>>> This is right before GVN:<br>
>>>>><br>
>>>>> define i32 @foo(<4 x i16> %p, <4 x i16> %p1, i16* nocapture %res)<br>
>>>>> local_unnamed_addr #0 !dbg !6 {<br>
>>>>> entry:<br>
>>>>> %temp = alloca i64, align 8<br>
>>>>> %tmpcast = bitcast i64* %temp to [4 x i16]*<br>
>>>>> %0 = bitcast i64* %temp to i8*, !dbg !8<br>
>>>>> call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %0) #3,<br>
>> !dbg !8<br>
>>>>> store i64 0, i64* %temp, align 8, !dbg !9<br>
>>>>> %1 = bitcast i64* %temp to <4 x i16>*, !dbg !10<br>
>>>>> %2 = call <4 x i16>* @llvm.XXX.intrinsic(<4 x i16>* nonnull %1, <4<br>
>> x<br>
>>>> i16><br>
>>>>> %p, i32 0), !dbg !11, !tbaa !12<br>
>>>>> %arrayidx = bitcast i64* %temp to i16*, !dbg !16<br>
>>>>> %3 = load i16, i16* %arrayidx, align 8, !dbg !16, !tbaa !17<br>
>>>>> br label %for.body, !dbg !19<br>
>>>>><br>
>>>>> for.body: ; preds = %entry<br>
>>>>> %arrayidx1 = getelementptr inbounds [4 x i16], [4 x i16]* %tmpcast,<br>
>>>> i32<br>
>>>>> 0, i32 1, !dbg !20<br>
>>>>> %4 = load i16, i16* %arrayidx1, align 2, !dbg !20, !tbaa !17<br>
>>>>> %cmp3 = icmp sgt i16 %3, %4, !dbg !21<br>
>>>>> %spec.select = select i1 %cmp3, i16 %4, i16 %3, !dbg !22<br>
>>>>> %arrayidx1.1 = getelementptr inbounds [4 x i16], [4 x i16]*<br>
>> %tmpcast,<br>
>>>> i32<br>
>>>>> 0, i32 2, !dbg !20<br>
>>>>> %5 = load i16, i16* %arrayidx1.1, align 2, !dbg !20, !tbaa !17<br>
>>>>> %cmp3.1 = icmp sgt i16 %spec.select, %5, !dbg !21<br>
>>>>> %spec.select.1 = select i1 %cmp3.1, i16 %5, i16 %spec.select, !dbg<br>
>> !22<br>
>>>>> %arrayidx1.2 = getelementptr inbounds [4 x i16], [4 x i16]*<br>
>> %tmpcast,<br>
>>>> i32<br>
>>>>> 0, i32 3, !dbg !20<br>
>>>>> %6 = load i16, i16* %arrayidx1.2, align 2, !dbg !20, !tbaa !17<br>
>>>>> %cmp3.2 = icmp sgt i16 %spec.select.1, %6, !dbg !21<br>
>>>>> %spec.select.2 = select i1 %cmp3.2, i16 %6, i16 %spec.select.1,<br>
>> !dbg<br>
>>>> !22<br>
>>>>> store i16 %spec.select.2, i16* %res, align 2, !dbg !23, !tbaa !17<br>
>>>>> %7 = tail call <4 x i16>* @llvm.XXX.intrinsic(<4 x i16>* %2, <4 x<br>
>> i16><br>
>>>>> %p1, i32 0), !dbg !24, !tbaa !12<br>
>>>>> %8 = load i16, i16* %arrayidx, align 8, !dbg !25, !tbaa !17<br>
>>>>> br label %for.body12, !dbg !26<br>
>>>>><br>
>>>>> for.body12: ; preds = %for.body<br>
>>>>> %arrayidx14 = getelementptr inbounds [4 x i16], [4 x i16]*<br>
>> %tmpcast,<br>
>>>> i32<br>
>>>>> 0, i32 1, !dbg !27<br>
>>>>> %9 = load i16, i16* %arrayidx14, align 2, !dbg !27, !tbaa !17<br>
>>>>> %cmp16 = icmp sgt i16 %8, %9, !dbg !28<br>
>>>>> %spec.select39 = select i1 %cmp16, i16 %9, i16 %8, !dbg !29<br>
>>>>> %arrayidx14.1 = getelementptr inbounds [4 x i16], [4 x i16]*<br>
>> %tmpcast,<br>
>>>>> i32 0, i32 2, !dbg !27<br>
>>>>> %10 = load i16, i16* %arrayidx14.1, align 2, !dbg !27, !tbaa !17<br>
>>>>> %cmp16.1 = icmp sgt i16 %spec.select39, %10, !dbg !28<br>
>>>>> %spec.select39.1 = select i1 %cmp16.1, i16 %10, i16 %spec.select39,<br>
>>>> !dbg<br>
>>>>> !29<br>
>>>>> %arrayidx14.2 = getelementptr inbounds [4 x i16], [4 x i16]*<br>
>> %tmpcast,<br>
>>>>> i32 0, i32 3, !dbg !27<br>
>>>>> %11 = load i16, i16* %arrayidx14.2, align 2, !dbg !27, !tbaa !17<br>
>>>>> %cmp16.2 = icmp sgt i16 %spec.select39.1, %11, !dbg !28<br>
>>>>> %spec.select39.2 = select i1 %cmp16.2, i16 %11, i16<br>
>> %spec.select39.1,<br>
>>>>> !dbg !29<br>
>>>>> %conv24 = sext i16 %spec.select39.2 to i32, !dbg !30<br>
>>>>> call void @llvm.lifetime.end.p0i8(i64 8, i8* nonnull %0) #3, !dbg<br>
>> !31<br>
>>>>> ret i32 %conv24, !dbg !32<br>
>>>>><br>
>>>>> On Thu, Jan 14, 2021 at 11:54 AM Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>><br>
>>>> wrote:<br>
>>>>>> It would be good to have an actual IR reproducer here.<br>
>>>>>><br>
>>>>>> On Thu, Jan 14, 2021 at 7:51 PM Ryan Taylor via llvm-dev<br>
>>>>>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>>>>>> So given an intrinsic that has a pointer as in/out and IntrWriteMem<br>
>>>>>> property.<br>
>>>>>>> call intrinsic(address a, ....);<br>
>>>>>>> loop over address a<br>
>>>>>>> load from address a + offset<br>
>>>>>>> call intrinsic (address a, ...);<br>
>>>>>>> loop over address a<br>
>>>>>>> load from address a + offset<br>
>>>>>>><br>
>>>>>>> GVN is removing the second loads, despite the second call overwriting<br>
>>>>>> the memory starting at address a. AA has the intrinsics marked as<br>
>>>> unknown<br>
>>>>>> instructions but has all of these as mayAlias in a set. I'm not seeing<br>
>>>> this<br>
>>>>>> issue with -fno-unroll-loops.<br>
>>>>>>> Thanks.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> LLVM Developers mailing list<br>
>>>>>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>>>>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>>>>> _______________________________________________<br>
>>>>> LLVM Developers mailing list<br>
>>>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>