<div dir="ltr">For loops with conditional stores, the EnableCondStoresVectorization feature allows the vectorizer to scalarize and predicate the stores in the vectorized loop. The same thing is done for conditional instructions that may divide by zero. In both cases the cost model does make an attempt to estimate the cost. It accounts for the cost of the extra inserts/extracts due to scalarization and the fact that the predicated blocks may not be executed the same number of times as the header. It currently assumes a block probably of 0.5 for predicated blocks and scales the costs of the predicated instructions accordingly.<div><div><br></div><div>You can take look at the AArch64/predication_costs.ll test to see some examples of how the cost is computed. This may give you some ideas as to what needs to be extended and/or modeled more accurately.<br><div><div><br></div><div>-- Matt</div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 20, 2017 at 4:59 AM, Jonas Paulsson via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 2017-03-17 23:23, Renato Golin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17 March 2017 at 16:34, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In general, this is true everywhere. In a large vectorized loop, this cost<br>
may well be worthwhile. The idea is that the cost model should account for<br>
all of these costs. If it doesn't properly, we should fix that.<br>
</blockquote>
Isn't this only worth when the SIMD instructions can be<br>
conditionalised per lane? I believe AVX512 and SVE have such<br>
abilities, but not NEON or SSE.<br>
<br>
Does SystemZ support conditionalisation in SIMD?<br>
<br>
</blockquote></span>
No, z13 has no masked vector operations. I think this is checked with the isLegalMasked...() hooks. Is this implicitly assumed in LoopVectorizers if-conversion algorithm somewhere? I see the scalar costs are adjusted with 'ScalarCost /= getReciprocalPredBlockProb()'. It seems that this should be done for all blocks that remain after vectorization?<br>
<br>
If not doing the simple thing and disabling store with predication vectorization, I agree with Hal that this could be worth modeling as an extra cost to not reject some large loop with just one conditional store, or so.<br>
<br>
I think this extra cost should be added to the compare, but I am not sure if it would be better to instead add it to the branch, because there are also cases of e.g. (AND (COMPARE, COMPARE)). Adding a cost to a vectorized branch instead could be done by assuming that a conditional branch would have to be set up for each branch after the vector compare.<br>
<br>
Does the loop vectorizer know which blocks that need predication in the scalar loop will remain after vectorization? SystemZ could check such blocks by looking for stores, but that seems like extra work.<br>
<br>
thanks,<br>
<br>
Jonas<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>