Determinism in the Inlining order?

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?



Intel WOS

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.

The support for bisecting LLVM has been implemented recently, see:
What exactly is missing to require you to implement your own?

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.


I’m not sure what you mean by “bisecting by callers” and “bisecting by callees”.
If you bisect differently that “stop-after XXX inlining”, then it is very likely your “bisecting” that introduces the issue you are seeing.