llvm dev - Apr 2016 - RFC: std::vector and identified objects

> 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

On 1 April 2016 at 17:30, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>> 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?
Right, that was more of a question really...

My reasoning is that, if LTO generated different versions of resize(),
some with constant folding at link time (due to the types of
arguments, ex. resize(256)), you could end up with a deeper inlining
and maybe get to a point where resize() is inlined into the caller for
that one particular case. This would expose the call to new(), and
therefore help the alias analysis to see that the pointers don't
alias.

That would be a poor man's version of compile-time inter-procedural
analysis, but at link time, if that makes any sense...

cheers,
--renato

> On Apr 1, 2016, at 9:35 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> 
> On 1 April 2016 at 17:30, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>>> 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?
> 
> Right, that was more of a question really...
> 
> My reasoning is that, if LTO generated different versions of resize(),
> some with constant folding at link time (due to the types of
> arguments, ex. resize(256)), you could end up with a deeper inlining
> and maybe get to a point where resize() is inlined into the caller for
> that one particular case. This would expose the call to new(), and
> therefore help the alias analysis to see that the pointers don't
> alias.
> 
> That would be a poor man's version of compile-time inter-procedural
> analysis, but at link time, if that makes any sense...
Oh it reminds me of a heuristic I wanted to explore: add an inlining bonus when
all the arguments to the function are constant at the call site (independently
of LTO or not).

-- 
Mehdi