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

[James Molloy via llvm-dev]

Hi,

Consider this code:
std::vector v;
v.resize(256);
for (i = 0; i < ... ; ++i) {
  a += v[b[i]];
}

This is a gather loop, and should be able to be vectorized. *however*...

I as a programmer can see that the size of v.data() is at least 256. I know
because of the contract of std::vector that v.data() is a unique heap
object that doesn't alias anything.

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.

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.

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 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.

Any information welcome :)

Cheers,

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160401/f6e7fcd8/attachment.html>