<div dir="ltr">Optimizations/LLVM in general are required to be deterministic, but we always have bugs.<br><br>That also doesn't mean that inlining can't seem "arbitrary" (ie: it might twitch between inlining and not depending on the order of functions, etc - I'm being really vague here & others may correct me that there's a stronger contract at work) that might make bisection/test case reduction difficult. It's possible that adding some alwaysinline and noinline attributes around to fix the inlining that exposes the bug may be helpful.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 30, 2016 at 11:14 AM Kevin Choi via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi all,<br><br></div>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?<br><br></div>Regards,<br></div>Kevin<br></div><br></div>Intel WOS<br></div>
_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>