<html><body bgcolor="#FFFFFF"><div>If builtin expects may end up disabling some optimizations, that indicates llvm should lower than early in compilation before any optimization passes. </div><div><br></div><div>Evan<br><br>On Jul 12, 2011, at 4:01 PM, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div><div>On Jul 12, 2011, at 2:24 PM, Jakub Staszak wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Andy,</div><div><br></div>Optimizations can always be harmed by intrinsics (e.g. Instruction Combiner). Because of that we remove expect intrinsics at the same beginning before any optimizations.<div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>-Kuba</div></span>
</div>
</div></blockquote><div><br></div><div>Part of the answer to my question is that the intrinsic replaces the uses of the original value. Naturally that's a serious problem for anyone following the def-use chain. I'm not sure why you wanted to define the intrinsic that way. Presumably because we can't pin it to a block?</div><div><br></div><div>Ideally you want a positional intrinsic interpreted as such: the value operand takes on the expected constant on any path dominated by the intrinsic. There should be no need to violate the def-use chain.</div><div><br></div><div>-Andy</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">On Jul 12, 2011, at 2:01 PM, Andrew Trick wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 7, 2011, at 1:48 PM, Jakub Staszak wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Right now clang creates "expect" intrinsic for every __builtin_expect instruction. These intrinsics must be lowered early because in other case they can harm other optimizations. During the lowering we also create "branch_weight" metadata, which can be used by other optimizations using BranchProbability analysis.</div></blockquote><div><br></div><div>Kuba,</div><div><br></div><div>Which optimizations are harmed by expect intrinsics?</div><div><br></div><div>If this is just a temporary solution, that's fine. In the long term, we need to formalize the properties of intrinsics that serve as positional meta-data. This is needed for debug info, exception handling, lifetimes, profiling, and probably more to come. We should have a uniform framework for these that guarantee they maintain their association with a control flow edge without affecting any optimizations or heuristics. BasicBlock::getFirstNonPHIOrDbgOrLifetime is a glaring example of the need for a general solution.</div><div><br></div><div>Three representations of almost exactly the same information (intrinsics, meta-data, and analysis) is also evidence of a design shortcoming.</div><div><br></div><div>-Andy</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">On Jul 6, 2011, at 5:31 PM, Chris Lattner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Jul 6, 2011, at 11:22 AM, Jakub Staszak wrote:<br><br><blockquote type="cite">Author: kuba<br></blockquote><blockquote type="cite">Date: Wed Jul 6 13:22:43 2011<br></blockquote><blockquote type="cite">New Revision: 134516<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">URL: <a href="http://llvm.org/viewvc/llvm-project?rev=134516&view=rev"><a href="http://llvm.org/viewvc/llvm-project?rev=134516&view=rev">http://llvm.org/viewvc/llvm-project?rev=134516&view=rev</a></a><br></blockquote><blockquote type="cite">Log:<br></blockquote><blockquote type="cite">Introduce "expect" intrinsic instructions.<br></blockquote><blockquote type="cite"><br></blockquote><br>Hi Kuba,<br><br>Why is this introducing a new pass to do lowering?<br><br>-Chris<br></div></blockquote><br>
_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu"><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a></a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></a><br></blockquote></div><br></div>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu"><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a></a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></a><br></blockquote><br></blockquote></div><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>llvm-commits mailing list</span><br><span><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></span><br></div></blockquote></body></html>