[llvm-dev] RFC: std::vector and identified objects

[Renato Golin via llvm-dev]

On 1 April 2016 at 08:56, James Molloy via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> However, LLVM knows none of this. Only if I force-inline
> std::vector::__append and friends does LLVM actually see the operator
> new(256) call - without that LLVM has no idea of the underlying storage of
> v, or of its size.

This looks like an inlining issue...



> Now, the vectorizer can emit runtime pointer checks, but one thing it
> absolutely requires is knowledge of the maximum size of a pointed-to object
> so it can do range intersection analysis. Without this information, it can't
> even emit a runtime pointer check.

Yup.


> So this RFC is about what exactly is going wrong here. I don't understand
> quite how we intend LLVM to gain this information - are we missing some
> intrinsics or abstractions? Or is the inliner just doing a poor job?

I wouldn't say "poor job", as inlining heuristics are complicated, but
I think that's one of the corner cases, yes.

I'm guessing the levels of indirection in this case are high enough
that the inliner gives up? I can't imagine resize being big enough to
pass the heuristics threshold, even after inlining everything.

An alternative would be inter-procedural analysis, but that's a big
monster in itself, and would require the target function (resize) to
have been totally inlined anyway, which is one step away from the
final inlining.


> I can't imagine that in the common case inlining all the way to operator
> new() would be beneficial - it's only beneficial in this case because the
> object is newly constructed so all of the branches in __append can be folded
> away when inlining.

Isn't this a case for LTO inlining / specialization?

cheers,
--renato