[llvm-dev] Determinism in the Inlining order?

[David Blaikie via llvm-dev]

Optimizations/LLVM in general are required to be deterministic, but we
always have bugs.

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.

On Tue, Aug 30, 2016 at 11:14 AM Kevin Choi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
>
> 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?
>
> Regards,
> Kevin
>
> Intel WOS
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160831/e5ef0a6c/attachment.html>