The Records already have a member `unsigned ID` which is unique. Specializing the less/hash traits classes to perform the less/hashing on that `unsigned` will result in deterministic behavior (since the nondeterminism arises entirely from the pointer values; both "<" and the hash functions are deterministic (although the hash table order might change more than comfortable with small changes to the .td files or the backend)). My question is mostly looking for ideas about how to perform the migration. There are numerous places in the backends where this nondeterminism is attacked in various "ad-hoc" ways, and it seems like a more coherent "right by design" approach is needed.<div>
<br></div><div>For example, I ran into all of the following:</div><div><br></div><div>* Places where a custom comparator is passed to map/set (there are no fewer than 3 custom comparators across the backends). With these, it is not usually clear without really understanding the code whether the actual order is actually important for the emission, or whether it is "just" to avoid the nondeterminism.</div>
<div>* Don't use a custom comparator, but sort afterwards. Like the above, with these its not usually clear without really understanding the code whether the sort is actually an important part of what is being emitted, or a band-aid for the nondeterministic container order.</div>
<div>* Just use nondeterministic order (AsmMatcherEmitter.cpp is particularly nasty). These are usually littered with bare std::map/set, with no typedefs to show what the types are semantically, so without fully understanding the code it is not possible to perform any maintenance that would result in any appreciable unification/simplification of the handling of the nondeterminism.</div>
<div><br></div><div>Maybe a good first step would be to instrument TableGen to force the pointer values to be "really nondeterministic" so that problems will crop up if they exist? Up until now all I have been doing has been to make a dummy git repo in my build directory and add all .inc files to it; then make changes and rebuild the .inc files, and git-diff to see changes. Any suggestions?</div>
<div><br></div><div>--Sean Silva<br><div><br><div class="gmail_quote">On Wed, Jun 20, 2012 at 11:28 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif"><font><div class="gmail_quote"><div class="im">On Wed, Jun 20, 2012 at 11:23 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wow that got incredibly mangled somehow. it was meant to say:<div><br></div><div><span style="font-size:13px;font-family:arial,sans-serif">"Thank you Jakob for patiently </span><span style="font-size:13px;font-family:arial,sans-serif">walking me through my first non-trivial patch set! I'll see what I can do </span><span style="font-size:13px;font-family:arial,sans-serif">to ensure deterministic iteration order.</span><span style="font-size:13px;font-family:arial,sans-serif">"</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">I'm still looking for a way to ensure deterministic iteration order without making a mess of the code, such as just blindly adding a special comparator to each of containers keyed on pointers; that would just make the code more muddled (even in cases where the container isn't being iterated over). There are also a couple hash tables that are keyed on Record*'s, which I think can be changed but I'm not familiar enough with the hash traits that they use. </span><span style="font-size:13px;font-family:arial,sans-serif">Any ideas for a good way to migrate to stable iteration interfaces? Thankfully, each Record has a field `unsigned ID;` which uniquely identifies it, so redirecting any hash/compare to that should be safe.</span></div>
</blockquote><div><br></div></div><div>I think introducing similar ID fields which are stable is the best strategy.</div><div><br></div><div>In particular, I like to dump the hashtable to a vector, and then sort on the stable key.</div>
<div><br></div><div>If you're lacking one of them, a common easy way to synthesize such an ID is to track order-of-allocation in the ID variable using a global atomic counter of some form. </div></div></font></div>
</blockquote></div><br></div></div>