Hi Nadav,<br><br>On Thu, Jan 3, 2013 at 1:53 PM, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank">nrotem@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Akira!<br>
<div class="im"><br>
><br>
> Does the current loop vectorizer inquire about the SIMD capabilities of the target architecture when it decides whether it is profitable to vectorize a loop?<br>
<br>
</div>Yes, it uses a cost model to determine the profitability of vectorization. At the moment only x86 provides the necessary hooks that are needed for calculating the costs. We may need to change the cost defaults to prevent vectorization on targets that don't implement the cost interface. If this is a problem for you then I can do it soon.<br>

<div class="im"><br></div></blockquote><div><br>I guess I can just implement all the vectorTargetTransformInfo::get*OpCost functions since I will later need a cost model for mips-dsp anyway.<br><br>Would the code in LoopVectorizationCostModel::expectedCost work correctly if those functions returned a large integer (max unsigned int)? I am concerned about overflow.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> I am asking this because I would like to have loop vectorization disabled for targets that don't support SIMD instructions (for example, standard mips32).<br>
> Loop vectorization bloats the code size and prolongs compilation time without any improvement to performance for such targets.<br>
><br>
<br>
</div>Yes. Also, notice that the loop vectorizer tries to be more conservative when the 'optforsize' attribute is used.<br>
<br>
<br>
Thanks,<br>
Nadav<br>
<br>
</blockquote></div><br>