[llvm-commits] [cfe-commits] TableGen backend API refactoring review request

Sean Silva silvas at purdue.edu
Wed Jun 20 23:57:50 PDT 2012


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.

For example, I ran into all of the following:

* 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.
* 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.
* 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.

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?

--Sean Silva

On Wed, Jun 20, 2012 at 11:28 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Wed, Jun 20, 2012 at 11:23 PM, Sean Silva <silvas at purdue.edu> wrote:
>
>> Wow that got incredibly mangled somehow. it was meant to say:
>>
>> "Thank you Jakob for patiently walking me through my first non-trivial
>> patch set! I'll see what I can do to ensure deterministic iteration
>> order."
>>
>> 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. 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.
>>
>
> I think introducing similar ID fields which are stable is the best
> strategy.
>
> In particular, I like to dump the hashtable to a vector, and then sort on
> the stable key.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120620/2182ffb6/attachment.html>


More information about the llvm-commits mailing list