<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Thanks all for replies. </div>
<div><br>
</div>
<div>Does LLVM  have a separate VBE pass? I couldn't find one. Although VBE is primarily for a code size, I see a case that VBE can affect following optimizations to reduce redundant moves in the binary. </div>
<div><br>
</div>
<div>Daniel, great to hear that you are working on a more advanced GVN implementation. I wonder if you have a timeline to upstream yours. </div>
<div><br>
</div>
<div>Best,</div>
<div>Taewook</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, February 9, 2016 at 12:28 PM<br>
<span style="font-weight:bold">To: </span>Taewook Oh <<a href="mailto:twoh@fb.com">twoh@fb.com</a>><br>
<span style="font-weight:bold">Cc: </span>mats petersson <<a href="mailto:mats@planetcatfish.com">mats@planetcatfish.com</a>>, "<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [llvm-dev] [GVN] same sequence of instructions in if and else branch<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">and by "right thing" i mean it can hoist if you want and it can prove it will not extend the live range.
<div><br>
</div>
<div>Note that VBE (very busy expressions) is a code size optimization only. It does not save time.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 9, 2016 at 12:26 PM, Daniel Berlin <span dir="ltr">
<<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">This GVN does not do that, this is correct. It is a very simple GVN. All phi nodes are considered to have unique values.
<div>GCC's GVN, and the one i'm developing for LLVM at <a href="https://github.com/dberlin/llvm-gvn-rewrite" target="_blank">
https://github.com/dberlin/llvm-gvn-rewrite</a>  does the right thing.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 9, 2016 at 11:42 AM, Taewook Oh 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">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>There is a phi-node "%phi = phi i64 [%cast1, %if], [%cast2, %else]" in the common successor. The actual control flow is a bit more complex, but there is a common successor block, and %cast1 and %cast2 are the two values that the phi node in the common
 successor takes.</div>
<div><br>
</div>
<div>Does the existence of the phi node affect optimization?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Taewook</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span><<a href="mailto:mats.o.petersson@googlemail.com" target="_blank">mats.o.petersson@googlemail.com</a>> on behalf of mats petersson <<a href="mailto:mats@planetcatfish.com" target="_blank">mats@planetcatfish.com</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, February 9, 2016 at 11:34 AM<br>
<span style="font-weight:bold">To: </span>Taewook Oh <<a href="mailto:twoh@fb.com" target="_blank">twoh@fb.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [llvm-dev] [GVN] same sequence of instructions in if and else branch<br>
</div>
<div>
<div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div>And there's no PHI node after this that depends on the condition?<br>
<br>
--<br>
</div>
Mats<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 February 2016 at 19:30, Taewook Oh 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">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<p><span>Hello, </span></p>
<p><span></span><br>
</p>
<p><span>I found that GVN doesn't promote identical sequence of instructions in if and else branch to their common predecessors. For example, for the following code snippet</span></p>
<p><span></span><br>
</p>
<p><span>pred:</span></p>
<p><span><span></span>…</span></p>
<p><span><span></span>br i1 %cmp, label %if, label %else</span></p>
<p><span>if:</span></p>
<p><span><span></span>%incdec.ptr.1 = getelementptr inbounds i8, i8* %ptr, i64 1</span></p>
<p><span><span></span>%cast1 = ptrtoint i8* %incdec.ptr.1 to i64</span></p>
<p><span>   <span> </span>…</span></p>
<p><span>else:</span></p>
<p><span><span></span>%incdec.ptr.2 = getelementptr inbounds i8, i8* %ptr, i64 1</span></p>
<p><span><span></span>%cast2 = ptrtoint i8* %incdec.ptr.2 to i64</span></p>
<p><span></span><br>
</p>
<p><span>GVN doesn't move instructions in 'if' and 'else' blocks to 'pred' block even though it knows that incdec.ptr.1/case1 has a same value number with incdec.ptr.2/cast2. I see a case where this kind of redundancy confuses following optimization passes
 and ends up generating suboptimal code. </span></p>
<p><span></span><br>
</p>
<p><span>From the GVN implementation, it seems that transformation is performed only when the "leader" value dominates the other value, so it cannot handle a case like the above example. I wonder if this is by design or just a missing feature. </span></p>
<p><span></span><br>
</p>
<p><span>Thanks,</span></p>
<p><span>Taewook</span></p>
</div>
</div>
<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://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=Xf5AAq_dBp5IcStlnft7nao-p-fDTN5AH6oItVXC3BA&s=4VUE3_dUQQ8AKzkWv5Tu6nJ979NtsOIq3qVC7CipHL8&e=" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</span></div>
<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://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=odyMzWAVRsllwAiB8t4HxXDitjnyM3jpIDKTeJ7R9cU&s=qUYTUrwO6X2i6yPxLpCfdpEFL6q5AtiKHTfIdwO7Pvo&e=" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>