<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>I needed to do finer grain bisecting on the inliner because the bug would only manifest after inlining happened at a specific callsite. Also, I was working with clang3.5, but I could have used newer. I ended up solving my bug, but I remember seeing when I bisected callees, it was giving conflicting result and I could not converge. Bisecting by callers still helped enough to solve the bug in my case.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Kevin<o:p></o:p></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><o:p> </o:p></span></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:mehdi.amini@apple.com">Mehdi Amini</a><br><b>Sent: </b>Wednesday, August 31, 2016 8:56 AM<br><b>To: </b><a href="mailto:code.kchoi@gmail.com">Kevin Choi</a><br><b>Cc: </b><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev</a><br><b>Subject: </b>Re: [llvm-dev] Determinism in the Inlining order?</p></div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><o:p> </o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> On Aug 30, 2016, at 11:14 AM, Kevin Choi via llvm-dev <llvm-dev@lists.llvm.org> wrote:</p><p class=MsoNormal>> </p><p class=MsoNormal>> Hi all,</p><p class=MsoNormal>> </p><p class=MsoNormal>> Just wanted to see if anyone could answer this dumb question I had. I wrote a bisector for the inliner based on caller/callee at Inliner.cpp, but I am getting conflicting results. Does anyone know if the inlining order is deterministic?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The support for bisecting LLVM has been implemented recently, see: http://llvm.org/docs/OptBisect.html</p><p class=MsoNormal>What exactly is missing to require you to implement your own?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>— </p><p class=MsoNormal>Mehdi</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>