<div dir="ltr"><div>Hello, some of the patches had conflicts with LLVM head, so I updated them. If you experienced patch failure before then you can try it again.</div><div><br></div><div>I compiled your code (1.c) with LLVM r308173 with the 5 patches applied, and it generated assembly like this. Now it contains store to c(%rip).</div><div>It tries to store a(%rip) + b(%rip) to c(%rip). I wish this translation is now correct.</div><div><br></div><div>```</div><div>73 .globl hoo # -- Begin function hoo</div><div>74 .p2align 4, 0x90</div><div>75 .type hoo,@function</div><div>76 hoo: # @hoo</div><div>77 .cfi_startproc</div><div>78 # BB#0:</div><div>79 movq a(%rip), %rax</div><div>80 movq cnt(%rip), %rcx</div><div>81 cmpq $0, i_hasval(%rip)</div><div>82 sete %sil</div><div>83 xorl %edx, %edx</div><div>84 .p2align 4, 0x90</div><div>85 .LBB1_1: # =>This Inner Loop Header: Depth=1</div><div>86 testb $1, %sil</div><div>87 je .LBB1_3</div><div>88 # BB#2: # in Loop: Header=BB1_1 Depth=1</div><div>89 movq b(%rip), %rsi</div><div>90 addq %rax, %rsi</div><div>91 movq %rsi, c(%rip)</div><div>92 movq $3, i_hasval(%rip)</div><div>93 incq %rdx</div><div>94 xorl %esi, %esi</div><div>95 cmpq %rcx, %rdx</div><div>96 jl .LBB1_1</div><div>97 .LBB1_3:</div><div>98 retq</div><div>```</div><div><br></div><div>IMHO, enhancing `isGuaranteedNotToBeUndefOrPoison` and using it as a precondition in loop unswitching is</div><div>not enough. undef (and poison) value can be stored into memory, and also be passed by a function argument.</div><div>`isGuaranteedNotToBeUndefOrPoison` will virtually return `false` for all cases except the value is</div><div>some integer constant. Sanjoy's suggestion might be helpful (if I understood correctly), but I'm</div><div>not sure how much it will be.</div><div><br></div><div>Best Regards,</div><div>Juneyoung Lee</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 18, 2017 at 3:43 AM, Sanjoy Das via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jul 17, 2017 at 11:21 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br>
>> On Mon, Jul 17, 2017 at 10:32 AM, Xinliang David Li <<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 agree<br>
>> > with Wei that other developers may also get hit by the same issue 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>
</span>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>
<div class="HOEnZb"><div class="h5">______________________________<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><font size="1">Juneyoung Lee</font><div><font size="1">Software Foundation Lab, Seoul National University</font></div></div></div>
</div>