On Tue, May 2, 2017 at 3:50 PM, Nathan Sidwell <nat...@acm.org> wrote:
> On the modules branch, I need rematerialize canonical types and the like
> from a read-in serialized tree.
>
> I discovered the canonical-type hash table is fed a bespoke hash value by
> each type creator. There was no generic type hasher :( The rationale
> appears to allow each type constuctor to just specialize its needs.
> Excitingly, a generic type hasher is hiding inside
> build_type_attribute_qual_variant. So I broke it out of there and
> generalized it a bit more.
>
> The type hashers had diverged from the attribute-variant hasher. This is
> not an error, because the attribute variant version was creating variants
> with non-null attributes, so guaranteed different But it was confusing.
>
> This generic hasher is slightly different to the bespoke hashers in a few
> places. One place of note was the vector type hasher, which mixed {elt-type,
> num-elts, vector-mode}, but vector-mode is entirely determined by the first
> two object, so mixing it in doesn't add any entropy. I dropped the mode.
>
> I still kept generating the hashvalue separate to the type_hash_canon call
> itself. Perhaps a future patch could change that, but I didn't want to much
> churn in this patch.
>
> I've included Jakub's recent TYPE_TYPELESS_STORAGE changes. (And notice that
> the attribute-type hasher wasn't dealing with it.)
>
> booted and tested on x86_64-linux-gnu, ok?
Looks ok to me. The new function name 'type_hash_default' is a little
odd, maybe
name it type_hash_canon_hash instead?
Thanks,
Richard.
> nathan
> --
> Nathan Sidwell
