<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 4, 2016 at 9:18 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Fri, Dec 2, 2016 at 9:24 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Dec 2, 2016 at 3:52 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm not familiar with GVN, but even if it is similar to it, I don' think I <i>should</i> use the same term used there. I originally chose GroupId because it was a group id (and the term "group" is used in gold's safe ICF paper to describe the concept <a href="http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36912.pdf" target="_blank">http://static.googleuserconten<wbr>t.com/media/research.google.co<wbr>m/en//pubs/archive/36912.pdf</a>), and then changed it to Color because it's one word and easy to digest than GroupId to me (e.g. we'll just color them in different colors!). Congruence class is, well, it sounds too technical and doesn't improve readability at least to me.</div></blockquote><div><br></div></span><div>Personally, I'm pretty opposed to the term "color" here. In all the cases I can think of, algorithms that refer to "colors" the number of different colors is a constant (one talks about "k-colorability" etc.; the "k" is always a constant). That is not the case in this context and it is really confusing. This is *not* a coloring algorithm; coloring algorithms are about local constraints where adjacent things can't be colored the same.</div></div></div></div></blockquote><div><br></div></span><div>If you feel strongly about that, I'm fine to change the term, but how do you describe it?</div><div><br></div><div>I think congruence class is defined as this: if two sections are in the same congruence class, they are identical.</div><div><br></div><div>That refers the result of the algorithm. We cannot say that we split congruence class into smaller congruence classes on each iteration, because if a congruence class can be split, it wasn't a congruence class.</div></div></div></div></blockquote><div><br></div><div>Not quite. You can think about it like each iteration makes the congruence relation more precise, until "section A is congruent to section B" means "section A is identical to B". That is why the term "congruent" is used instead of "identical".<br></div><div><div>For an optimistic algorithm, we initially consider all sections congruent. Then we apply a series of refinements to the congruence relation until we know that if two sections are congruent, then they are identical.</div></div><div><br></div><div>The sense of the term "congruent" is similar to this sense in math: <a href="http://mathworld.wolfram.com/Congruence.html">http://mathworld.wolfram.com/Congruence.html</a></div><div>I.e. "congruent" means "identical in this regard", and there is a special symbol (the equal sign with three lines) to represent this, to distinguish it from truly "identical".</div><div><br></div><div><br></div><div>I agree with you that congruence is fairly technical terminology. "equivalence class" means the same thing and is easier to understand.</div><div><br></div><div>I think the description we already had is quite good:</div><div><br></div><div>```</div><div><span style="font-size:12.8px">-// We begin by optimistically putting all sections into a single equivalence</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// class. Then we apply a series of checks that split this initial</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// equivalence class into more and more refined equivalence classes based on</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// the properties by which a section can be distinguished.</span><br style="font-size:12.8px"><span style="font-size:12.8px">-//</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// We begin by checking that the section contents and flags are the</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// same. This only needs to be done once since these properties don't depend</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// on the current equivalence class assignment.</span><br style="font-size:12.8px"><span style="font-size:12.8px">-//</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// Then we split the equivalence classes based on checking that their</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// relocations are the same, where relocation targets are compared by their</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// equivalence class, not the concrete section. This may need to be done</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// multiple times because as the equivalence classes are refined, two</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// sections that had a relocation target in the same equivalence class may</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// now target different equivalence classes, and hence these two sections</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// must be put in different equivalence classes (whereas in the previous</span><br style="font-size:12.8px"><span style="font-size:12.8px">-// iteration they were not since the relocation target was the same.)</span><br></div><div>```</div><div><br></div><div><br></div><div>Mostly, I just really object to the use of the term "color" because it is really confusing in this context.</div><div><br></div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-h5"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>GVN/CSE and the term "congruence" (or even "equivalence class") is technically correct. GroupId is consistent with the paper at least. But "coloring" is just wrong.</div><span class="gmail-m_-4085064659375035456HOEnZb"><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-4085064659375035456m_-8481197221145679097HOEnZb"><div class="gmail-m_-4085064659375035456m_-8481197221145679097h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 2, 2016 at 12:46 AM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Dec 2, 2016 at 12:35 AM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Fri, Dec 2, 2016 at 12:34 AM, Sean Silva via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
><br>
> On Thu, Dec 1, 2016 at 11:45 AM, Rui Ueyama via llvm-commits<br>
> <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
>><br>
>> Author: ruiu<br>
>> Date: Thu Dec  1 13:45:22 2016<br>
>> New Revision: 288409<br>
>><br>
>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=288409&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-pr<wbr>oject?rev=288409&view=rev</a><br>
>> Log:<br>
>> Updates file comments and variable names.<br>
>><br>
>> Use "color" instead of "group id" to describe the ICF algorithm.<br>
><br>
><br>
> The right term is "congruence class"; I think you should use it. This ICF<br>
> algorithm is basically a simple "optimistic" GVN/CSE algorithm; all values<br>
> are initially assumed to be in the same congruence class and then that<br>
> equivalence class is iteratively split as contradictions are found until<br>
> there are no contradictions.<br>
><br>
<br>
</span>+1, I think the proper term is congruence here.<br></blockquote><div><br></div></span><div>I think you've been working on NewGVN for long enough to know better than "I think" ;)</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-m_-4085064659375035456m_-8481197221145679097m_8221748402588099965m_-4000831247460638509HOEnZb"><font color="#888888"><br><span class="gmail-m_-4085064659375035456m_-8481197221145679097m_8221748402588099965HOEnZb"><font color="#888888">
--<br>
Davide<br>
</font></span></font></span></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>