<div dir="ltr">Hi folks,<div><br></div><div>I've been thinking on how to implement some of the costs and there is a lot of instructions which cost depend on other instructions around. Casts are one obvious case, since arithmetic and memory instructions can, sometimes, cast values for free.</div>
<div><br></div><div style>The cost model receives Opcodes, which lose the info on the history of the values being vectorized, and I thought we could pass the whole Instruction instead. But this is the easy part... Below are some  ideas which I'd love to hear from you guys which makes sense and which doesn't...</div>
<div style><br></div><div style>A. How to find context?</div><div style><br></div><div style>Suppose you have a cast instruction, and you want to find out if there is an arithmetic operations before (or after) on any of the values it touches...</div>
<div style><br></div><div style>%3 = sext %type1 %2 to %type2</div><div style><br></div><div style>You could iterate through all uses of %3 and %2 and see if any of them is a mul/add/sub, and return 'true', so that the cost would add (or not) an extra cycle.</div>
<div style><br></div><div style>Problems:</div><div style><br></div><div style>1. This space is multi-dimensional, ie. there are many types in and many out, and the cost table is not linear on any of the dimensions (hence, cost tables). An idea is to create a multi-dimension cost table, but that could get confusing really quickly.</div>
<div style><br></div><div style>2. We're essentially reproducing the logic of Inst Combine, which is not sensible nor appropriate.</div><div style><br></div><div style>Any ideas on direction for this one?</div><div style>
<br></div><div style><br></div><div style>B. How to find resulting code?</div><div style><br></div><div style>Another alternative is to run some lower level passes on the code, to reduce the chances that we're guessing in the dark, but that'd be extremely expensive. Maybe we can only run the vectorizer at the very end, and only if code changed, that we'd re-ruin again the clean-up passes. I'm not convinced...</div>
<div style><br></div><div style><br></div><div style>C. Settle for guess in the dark</div><div style><br></div><div style>We can continue guessing in the dark, but do it consistently. This is our approach, and I'm, wondering if it makes sense to deviate from it.</div>
<div style><br></div><div style>My main issue is that the costs for ARM instructions are almost random when seen from an IR perspective, we're bound to make as many mistakes as not.</div><div style><br></div><div style>
Another issue is that the number of vector IR instructions (extract/select) is a lot more than the resulting vector code, and that can count negatively on the benefits of vectorizing.</div><div style><br></div><div style>
<br></div><div style>It's also quite possible that I'm over-thinking...</div><div style><br></div><div style>Thoughts?</div><div style><br></div><div style>cheers,</div><div style>--renato</div><div style><br></div>
</div>