> On May 6, 2015, at 2:52 PM, David Blaikie <[email protected]> wrote:
>
>
>
> On Wed, May 6, 2015 at 2:45 PM, Adrian Prantl <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On May 6, 2015, at 2:35 PM, Eric Christopher <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> That said, add enough to the name for hashing purposes to make it hash
>> uniquely? Or you can go down the path of hashing the type similar to the
>> fission CU hashing (which is what type units were arguably designed to do in
>> the first place if you take a look at the standard, we just only use them
>> for ODR compliant languages etc right now).
>
> I suppose one could hash the entire module configuration + the mangled name
> and get something that is relatively stable.
> For implementation reasons it would be terrible to do the full fission
> hashing because that would mean that we would actually have to look up (and
> deserialize the type) in order to get to its ID when emitting an external
> type reference, which would void at least some of the performance gains we
> want from module debugging.
>
> I thought you were proposing using the mangled name of the type for the
> identifier anyway? Perhaps I misunderstood - what are you proposing to use?
> In any case, I'd prefer to see whatever it is hashed and used as the type
> unit signature for compatibility with DWARF5, rather than adding an
> extra/separate/new/non-standard way to do cross-unit/cross-fission type
> references.
In the IR I’d /like/ to have a DIExternalTypeRef(DW_TAG_class_type,
!”_ZTC6TypeName”, !1) with !1 being a reference to either the DIModule or the
skeleton CU. Then the backend would emit the hash of the name if type units are
enabled (C++/gdb) or the mangled name (+ the accelerator table entry) otherwise
(ObjC and/or Darwin). If there is significant pushback to the latter, I’d be
willing to have the backend emit a hash in both cases but we’d have to careful
about what to exactly to hash for all the aforementioned reasons.
-- adrian
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
