<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 6:06 AM, Pete Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div>On Jan 5, 2015, at 7:50 AM, Liu Xin <<a href="mailto:navy.xliu@gmail.com" target="_blank">navy.xliu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">hi, Pete, <div><br><div>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><br></div><div>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>Honestly, I'm not sold on this one.</div><div class="gmail_extra"><br></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 class="gmail_extra"><br></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>