<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Hi Sanjoy,</div>
<div> </div>
<div>Please see my answers bellow:</div>
<div> </div>
<div> - Core motivation: why do we even care about optimizing floating</div>
<div> point induction variables? What situations are they common in? Do</div>
<div> programmers _expect_ compilers to optimize them well? (I haven't</div>
<div> worked on our vectorizers so pardon the possibly stupid question)</div>
<div> in the example you gave, why do you need SCEV to analyze the</div>
<div> increment to vectorize the loop (i.e how does it help)? What are</div>
<div> some other concrete cases you'll want to optimize?</div>
<div> </div>
<div><b><i>[Demikhovsky, Elena] </i></b><b><i>I gave an example of loop that can be vectorized in </i></b><b><i>the </i></b><b><i>fast-math m</i></b><b><i>ode. ICC compiler vectorizes </i></b><b><i>loops with *primary* and *secondary* </i></b><b><i>IVs</i></b><b><i>:</i></b></div>
<div><b><i>This is the examp</i></b><b><i>le for *primary* induction:</i></b></div>
<div> </div>
<div><b><i>(1) </i></b><b><i>for (float i = 0.5; i < 0.</i></b><b><i>75; i+=0.05) {}</i></b><b><i> </i></b><b><i> → </i></b><b><i>i is a </i></b><b><i>"</i></b><b><i>primary</i></b><b><i>"</i></b><b><i> IV</i></b></div>
<div> </div>
<div><b><i>And for *secondary*</i></b><b><i>:</i></b></div>
<div> </div>
<div><b><i>(2) </i></b><b><i>for (int i = 0</i></b><b><i>, float x = </i></b><b><i>start</i></b><b><i>; i < N; i++, x += </i></b><b><i>delta) {}</i></b><b><i> </i></b><b><i> → </i></b><b><i>x is </i></b><b><i>a </i></b><b><i>"</i></b><b><i>secondary</i></b><b><i>"</i></b><b><i>
IV</i></b></div>
<div> </div>
<div><b><i>Now</i></b><b><i> I'm working </i></b><b><i>only </i></b><b><i>on (2)</i></b></div>
<div> </div>
<div> - I presume you'll want SCEV expressions for `sitofp` and `uitofp`.</div>
<div> </div>
<div><b><i>[Demikhovsky, Elena] </i></b><b><i>I'm adding these expressions, of course. They are similar to </i></b><b><i>"</i></b><b><i>trunca</i></b><b><i>te" and "zext", in terms of implementation.</i></b></div>
<div> </div>
<div> (The most important question:) With these in the game, what is the</div>
<div> canonical representation of SCEV expressions that can be expressed</div>
<div> as, say, both `sitofp(A + B)` and `sitofp(A) + sitofp(B)`?</div>
<div><b><i>[Demikhovsky, Elena] </i></b><b><i>Meanwhile I have </i></b><b><i> (</i></b><b><i>start + </i></b><b><i>delta * sito</i></b><b><i>fp(i))</i></b><b><i>.</i></b></div>
<div><b><i>I don't </i></b><b><i>know how far </i></b><b><i>we can go with FP simplification and under what </i></b><b><i>flags. The first implementation does not assume that </i></b><b><i>sitofp(A + B</i></b><b><i>)</i></b><b><i> is equal to </i></b><b><i>sitofp(A)
+ sitofp(B)</i></b></div>
<div> </div>
<div> </div>
<div> Will we have a way to mark expressions (like we have `nsw` and</div>
<div> `nuw` for `sext` and `zext`) which we can distribute `sitofp` and</div>
<div> `uitofp` over?</div>
<div><b><i>[Demikhovsky, Elena] </i></b><b><i>I assume that sitofp and uitofp should be 2 diffe</i></b><b><i>rent operations. </i></b></div>
<div> </div>
<div> Same questions for `fptosi` and `fptoui`.</div>
<div><b><i>[Demikhovsky, Elena] </i></b><b><i>the same answer as above, because </i></b><b><i>I</i></b><b><i> don’t want</i></b><b><i> to combine these operations</i></b></div>
<div> </div>
<div> - How will you partition the logic between floating and integer</div>
<div> expressions in SCEV-land? Will you have, say, `SCEVAddExpr` do</div>
<div> different things based on type, or will you split it into</div>
<div> `SCEVIAddExpr` and `SCEVFAddExpr`? [0]</div>
<div> </div>
<div><b><i>[Demikhovsky, Elena] </i></b><b><i>Yes, </i></b><b><i>I’m introducing </i></b><b><i>SCEV</i></b><b><i>F</i></b><b><i>AddExpr</i></b><b><i> and </i></b><b><i>SCEV</i></b><b><i>FMul</i></b><b><i>Expr</i></b><b><i> - </i></b><b><i>(</i></b><b><i>start
+ </i></b><b><i>delta * sito</i></b><b><i>fp(i))</i></b></div>
<div> </div>
<div> * There are likely to be similarities too -- e.g. the "inductive"</div>
<div> or "control flow" aspect of `SCEVAddRecExpr` is likely to be</div>
<div> common between floating point add recurrences[1], and integer add</div>
<div> recurrences; and part of figuring out the partitioning is also</div>
<div> figuring out how to re-use these bits of logic.</div>
<div><b><i>[Demikhovsky, Elena] </i></b><b><i>I’m adding S</i></b><b><i>CEVFAddRecExpr to describe the recurrence of FP IV</i></b></div>
<div> </div>
<div> </div>
<div>[0]: I'll prefer the latter since e.g. integer addition is associative, but floating point addition isn't; and it is better to force programmers to handle the two operations differently.</div>
<div> </div>
<div>[1]: For instance, things like this:</div>
<div><a href="https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/ScalarEvolution.cpp#L7564">https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/ScalarEvolution.cpp#L7564</a></div>
<div>are likely to stay common between floating point and integer add recs.</div>
<div> </div>
<div>-- Sanjoy</div>
<div> </div>
</span></font>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></body>
</html>