[LLVMdev] should AlwaysInliner inline this case?

[Chandler Carruth]

On Mon, Jan 5, 2015 at 6:06 AM, Pete Cooper <peter_cooper at apple.com> wrote:

> On Jan 5, 2015, at 7:50 AM, Liu Xin <navy.xliu at gmail.com> wrote:
>
> hi, Pete,
>
> 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?
>
> I don't know the order for sure, but I know instcombine runs a few times
> so probably one of those is before alwaysinline.
>
> 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.
>

Honestly, I'm not sold on this one.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150106/57f8e4cc/attachment.html>