<div dir="ltr">On 14 October 2013 17:44, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank">nrotem@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks for working on this.  As you said, we don't support pointer reductions.  Handling pointer reductions should be straightforward. You can copy the logic for handling RK_IntegerAdd and create a new enum entry for RK_PointerAdd.</blockquote>
<div><br></div><div>Hi Nadav,</div><div><br></div><div>Thanks for the pointers, it's good to see that I wasn't too far away in the wrong direction. ;)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
You will need to detect the relevant patterns (GEP probably) and implement the cost model and vectorization parts.</blockquote><div><br></div><div>There are at least two patterns that I wish to implement: multiple pointers (previous example) and single pointer, like this:</div>
<div><br></div><div>for () {</div><div>  a = *read;</div><div>  ...</div><div>  *write = a;</div><div>}</div><div><br></div><div>They'll end up as the same type of vectorization, but the former only works if the operations on all inputs are identical (which is my case) and will most likely leave empty lanes in the vectors. But the second is a traditional vectorization (after loop unrolling) where, by definition, the operations are the same. </div>
<div><br></div><div>So, because I can have the multiple case, I'll have to check throughout all operations on all lanes to make sure they're identical, and that might put some stress on the vectorizer...</div><div>
<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">You will need to generate vector-geps that represent the pointer increment. Vector-GEPs are rare and this may trigger bugs in other parts of the compiler (Vector GEPs usually live between the vectorizer, which is a very late pass, until SelectionDAG builder). I wonder if this pattern is common.</blockquote>
<div><br></div><div>I'll pay special attention to them, and will blame you whenever I find a bug. ;)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Usually before I add new features to the vectorizer I write code that does an “fprintf” into a file every time I detect the pattern that I want to optimize.  Next, I run the LLVM test suite and look at the C files that triggered the patterns. This helps in estimating the profitability of the optimization and also to find additional interesting cases.<br>
</blockquote><div></div></div><br></div><div class="gmail_extra">That is an interesting instrumentation, I'll do that.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks!</div><div class="gmail_extra">
--renato</div></div>