<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 6, 2015, at 12:53 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jan 5, 2015 at 6:06 AM, Pete Cooper <span dir="ltr" class=""><<a href="mailto:peter_cooper@apple.com" target="_blank" class="">peter_cooper@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div class="">On Jan 5, 2015, at 7:50 AM, Liu Xin <<a href="mailto:navy.xliu@gmail.com" target="_blank" class="">navy.xliu@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">hi, Pete, <div class=""><br class=""><div class="">I understand InstCombine may simplify bitcast to nothing, but the order matters. AlwaysInliner happens in very early stage, and we never call it again. if InstCombine works, can we invoke it before Inliner?</div></div></div></div></blockquote></span>I don't know the order for sure, but I know instcombine runs a few times so probably one of those is before alwaysinline.<div class=""><br class=""></div><div class="">Arguably, if the pass order is an issue, I'd be fine with making the code David found be a utility that the inliner can call. Not sure if anyone else thinks that's out of scope for the inliner, but I like the idea of it being able to make a call more inlinable.</div></blockquote></div><br class="">Honestly, I'm not sold on this one.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">always_inline is a really murky thing to begin with. I think the only reasonable stance is to insist that if the frontend *really* needs the inline to occur, it should arrange for the inline to be trivially do-able. Relying on the always inliner (much less other passes) having any kind of folding in order for the inlining to occur seems really risky.</div></div></div></blockquote>Fair enough. I wasn’t hugely attached to the idea, just wanted to put it out there :)<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I'd actually like it if we could spec sufficiently restrictive rules, and make it a verify failure to violate them on a call marked always_inline so that frontends were required to diagnose this nicely to users or satisfy the constraints. Sadly, we are a very long way away from realizing a system like that. I think we should probably move in that direction though, even if it takes a long time to get there, as other patterns seem really hard to maintain and support long term.</div></div>
</div></blockquote></div><div>This would be nice. For this to work, you basically need always_inline to be the first thing that ever runs in the pass pipeline. Only if its first can the analysis run by the front-end still hold. Otherwise the optimizer might transform a call site in to something no longer inalienable. Or perhaps that would be considered an opt bug. it could get especially tricky with LTO if you have say all of -O3 then try to always_inline across linked modules.</div><div><br class=""></div><div>Pete</div><br class=""></body></html>