llvm dev - Aug 2016 - 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?

Regards,
Kevin

Intel WOS
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160830/008fbb12/attachment.html>

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>

> On 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?
The support for bisecting LLVM has been implemented recently, see:
http://llvm.org/docs/OptBisect.html
What exactly is missing to require you to implement your own?

— 
Mehdi

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.

-Kevin

From: Mehdi Amini
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160831/c400b254/attachment.html>