[llvm-dev] Determinism in the Inlining order?

[Mehdi Amini via llvm-dev]

> On Aug 31, 2016, at 9:12 AM, code.kchoi at gmail.com wrote:
> 
> 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.

— 
Mehdi


> .
>  
> -Kevin
>  
> From: Mehdi Amini <mailto:mehdi.amini at apple.com>
> Sent: Wednesday, August 31, 2016 8:56 AM
> To: Kevin Choi <mailto:code.kchoi at gmail.com>
> Cc: llvm-dev <mailto:llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Determinism in the Inlining order?
>  
>  
> > 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160831/7ab12fdd/attachment.html>