<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
By the way, to answer Andy's question. I did some experiment using the<br>
testcase in PR29065 to see if we regenerate SCEV for existing and<br>
expanded IR, whether it will be easier to check equivalence suppose we<br>
have SCEV cse rules. The reassociated order of generated SCEVs seems<br>
more consistent. For C= A1 + A2 + B above, the SCEV corresponding to<br>
A1 + A2 has the same computation sequence with the SCEV corresponding<br>
to A (A1, A2 and A are all complex SCEV themselves). However, during<br>
expansion, the cost of searching existing IR, convert them to SCEV and<br>
see if they are equivalent with the SCEV to be expanded looks<br>
expensive.</blockquote><div><br></div><div>Is this the cost of processing every instruction, or just things that look like recurrences?</div><div> </div><div>I ask mainly because i'm curious if the cost decreases if you limit this part to recurrences, and did something like have VN just take recurrences (which are cheap to find as SCC's in the SSA graph), if you have >1 recurrence, and see if they are SCEVable.</div><div><br></div><div>You'd still need to define equivalence, of course.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> And we need to add complex rules to define SCEV equivalence<br>
from CSE perspective. </blockquote><div><br></div><div><br></div></div></div></div>