<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 1:53 PM, Wei Mi <span dir="ltr"><<a href="mailto:wmi@google.com" target="_blank">wmi@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems MemorySSA.cpp is the only real code where we found the<br>
problem happening.</blockquote><div><br></div><div>This is doubtful, ¸FWIW :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Is it possible to change the source of<br>
MemorySSA.cpp to hide the problem and buy some time for now? Now we<br>
use an empty generic_def_path_iterator with Optional<ListIndex> N<br>
being initialized by None as the end of range. Can we initialize the<br>
Optional var with a special value instead of None?<br>
<br>
iterator_range<def_path_<wbr>iterator> def_path(ListIndex From) {<br>
return make_range(def_path_iterator(<wbr>this, From), def_path_iterator());<br>
<div class="HOEnZb"><div class="h5"> }<br>
<br></div></div></blockquote><div><br></div><div>Why does this work?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
On Mon, Jul 17, 2017 at 1:37 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br>
> I think everyone agrees pretty much everything short of "Fix undef" will not<br>
> fix the problem for good.<br>
> I think we are more trying to hide it well enough that we get the months we<br>
> need for various folks to work on the larger proposals.<br>
> Which sucks, but not sure we have a better answer, because i don't think we<br>
> are going to commit the freeze/etc patches tomorrow.<br>
><br>
><br>
> On Mon, Jul 17, 2017 at 1:34 PM, Juneyoung Lee <<a href="mailto:juneyoung.lee@sf.snu.ac.kr">juneyoung.lee@sf.snu.ac.kr</a>><br>
> wrote:<br>
>><br>
>> Hello, some of the patches had conflicts with LLVM head, so I updated<br>
>> them. If you experienced patch failure before then you can try it again.<br>
>><br>
>> I compiled your code (1.c) with LLVM r308173 with the 5 patches applied,<br>
>> and it generated assembly like this. Now it contains store to c(%rip).<br>
>> It tries to store a(%rip) + b(%rip) to c(%rip). I wish this translation is<br>
>> now correct.<br>
>><br>
>> ```<br>
>> 73 .globl hoo # -- Begin function hoo<br>
>> 74 .p2align 4, 0x90<br>
>> 75 .type hoo,@function<br>
>> 76 hoo: # @hoo<br>
>> 77 .cfi_startproc<br>
>> 78 # BB#0:<br>
>> 79 movq a(%rip), %rax<br>
>> 80 movq cnt(%rip), %rcx<br>
>> 81 cmpq $0, i_hasval(%rip)<br>
>> 82 sete %sil<br>
>> 83 xorl %edx, %edx<br>
>> 84 .p2align 4, 0x90<br>
>> 85 .LBB1_1: # =>This Inner Loop Header:<br>
>> Depth=1<br>
>> 86 testb $1, %sil<br>
>> 87 je .LBB1_3<br>
>> 88 # BB#2: # in Loop: Header=BB1_1<br>
>> Depth=1<br>
>> 89 movq b(%rip), %rsi<br>
>> 90 addq %rax, %rsi<br>
>> 91 movq %rsi, c(%rip)<br>
>> 92 movq $3, i_hasval(%rip)<br>
>> 93 incq %rdx<br>
>> 94 xorl %esi, %esi<br>
>> 95 cmpq %rcx, %rdx<br>
>> 96 jl .LBB1_1<br>
>> 97 .LBB1_3:<br>
>> 98 retq<br>
>> ```<br>
>><br>
>> IMHO, enhancing `<wbr>isGuaranteedNotToBeUndefOrPois<wbr>on` and using it as a<br>
>> precondition in loop unswitching is<br>
>> not enough. undef (and poison) value can be stored into memory, and also<br>
>> be passed by a function argument.<br>
>> `<wbr>isGuaranteedNotToBeUndefOrPois<wbr>on` will virtually return `false` for all<br>
>> cases except the value is<br>
>> some integer constant. Sanjoy's suggestion might be helpful (if I<br>
>> understood correctly), but I'm<br>
>> not sure how much it will be.<br>
>><br>
>> Best Regards,<br>
>> Juneyoung Lee<br>
>><br>
>> On Tue, Jul 18, 2017 at 3:43 AM, Sanjoy Das via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> On Mon, Jul 17, 2017 at 11:21 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>><br>
>>> wrote:<br>
>>> >> On Mon, Jul 17, 2017 at 10:32 AM, Xinliang David Li<br>
>>> >> <<a href="mailto:davidxl@google.com">davidxl@google.com</a>><br>
>>> >> wrote:<br>
>>> >> > The issue blocks another optimization patch and Wei has spent huge<br>
>>> >> > amount of<br>
>>> >> > effort isolating the the bootstrap failure to this same problem. I<br>
>>> >> > agree<br>
>>> >> > with Wei that other developers may also get hit by the same issue<br>
>>> >> > and<br>
>>> >> > the<br>
>>> >> > cost of leaving this issue open for long can be very high to the<br>
>>> >> > community.<br>
>>> >><br>
>>> >> I can't speak for others, but I am fine with adding a workaround for<br>
>>> >> this. However, I suspect isGuaranteedNotToBeUndefOrPois<wbr>on in<br>
>>> >> LoopUnswitch may regress other benchmarks.<br>
>>> ><br>
>>> > Any other thoughts on a more minimal fix?<br>
>>><br>
>>> I can't think of any good answers here.<br>
>>><br>
>>> The semantic we want is "branching on poison or undef is undefined<br>
>>> behavior" (which lets us do propagateEquality). Given that, we could<br>
>>> be clever about implementing isGuaranteedNotToBeUndefOrPois<wbr>on; for<br>
>>> instance if we have:<br>
>>><br>
>>> do {<br>
>>> if (a != b) {<br>
>>> ...<br>
>>> }<br>
>>> } while (...);<br>
>>><br>
>>> then we can use post-domination to prove that "a != b" is not undef<br>
>>> (otherwise the loop is guaranteed to have undefined behavior).<br>
>>><br>
>>> (I hate to say this), a more aggressive fix is to introduce a "freeze"<br>
>>> intrinsic that freezes only an i1. LoopUnswitch would wrap the loop<br>
>>> invariant condition in this after hoisting the branch. This would be<br>
>>> a poor man's version of the more invasive patches Juneyoung already<br>
>>> has developed.<br>
>>><br>
>>> -- Sanjoy<br>
>>> ______________________________<wbr>_________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> Juneyoung Lee<br>
>> Software Foundation Lab, Seoul National University<br>
><br>
><br>
</div></div></blockquote></div><br></div></div>