[llvm-dev] [RFC][InlineCost] Modeling JumpThreading (or similar) in inline cost model

[Davide Italiano via llvm-dev]

On Fri, Aug 4, 2017 at 11:06 AM, Daniel Berlin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> A few notes:
> I'm a bit surprised IPO copy/constant propagation doesn't get this case, but
> i didn't look if the lattice supports variables.

To the best of my knowledge (I haven't looked at this in the last 4-6
months) LLVM's lattice does not support variables, but I may be wrong
:)

> In particular, in your example, given no other call sites, it should
> eliminate the dead code.
> (In a real program, it may require cloning).
>
> GCC will do IPA-CP/const-prop with cloning, and i'm wildly curious if new
> GCC's catch this case for you at higher optimization levels?
>
> If so, it may be worth not looking at this as an inlining problem, but as an
> area we need IPO infrastructure improvement
>

FWIW, this also seems a lack of IPO infrastructure to me.
The lack of a real IPA for constant propagation inhibits other
optimizations (I think I have a few bug open about this).
GCC uses a variation of Callahan's algorithm that iterate SCCs in
topological order instead and keeps all possible candidates and then
has a very rudimental heuristic to decide which one to keep (and which
one to discard).
When I spoke with Honza Hubicka about this he claimed cloning doesn't
really give any benefit in large real world program (I think they
tried LibreOffice and Firefox), but he admitted the cost model wasn't
really tuned so that could be the problem.