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

[Mehdi Amini via llvm-dev]

> On Apr 1, 2016, at 3:19 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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?

I'm curious about what you have in mind exactly? What extra-information are available at LTO-time in this case compare to a non-LTO compilation? 

-- 
Mehdi