<div dir="ltr">Hi,<div><br></div><div>Consider this code:</div><div>std::vector v;</div><div>v.resize(256);</div><div>for (i = 0; i < ... ; ++i) {</div><div>  a += v[b[i]];</div><div>}</div><div><br></div><div>This is a gather loop, and should be able to be vectorized. <b>however</b>...</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Any information welcome :)</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div>