[PATCH] D96035: [dsymutil][DWARFlinker] implement separate multi-thread processing for compile units.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 29 12:26:16 PDT 2022


dblaikie added a comment.

In D96035#3686890 <https://reviews.llvm.org/D96035#3686890>, @avl wrote:

> In D96035#3685745 <https://reviews.llvm.org/D96035#3685745>, @dblaikie wrote:
>
>> In D96035#3685472 <https://reviews.llvm.org/D96035#3685472>, @avl wrote:
>>
>>> In D96035#3684041 <https://reviews.llvm.org/D96035#3684041>, @dreampiggy wrote:
>>>
>>>>> DW_TAG_thrown_type is currently not handled by new DWARFLinker(as well as by old DWARFLinker)
>>>>
>>>> Yes. But seems the old DWARFLinker DIECloner does not hit any assert and crash. Seems the new "artificial compile unit" based on types name will fail on this case ?
>>>
>>> yes, it will fail. Thus, it is necessary to add(other than adding specific handling for DW_TAG_thrown_type) default handler for unknown DW_TAG_* die. So that the patch do not crash in such a case. Will do this with nearest rebasing.
>>
>> So it sounds like there's a list of attributes that may be type attributes - is it possible to detect type references by the type of the referenced DIE instead of the attribute used to reference them? (or both?) or would DW_AT_sibling break that by causing a sibling attribute to be treated differently just because the sibling was a type?
>
> This exact case is not about how to detect whether an attribute references type DIE or not.
> (Though attributes referencing type die currently implemented as the predefined list: DW_AT_type, DW_AT_containing_type, DW_AT_specification, DW_AT_abstract_origin, DW_AT_import.)
> This case is about how to decide which DIE referencing type DIE should be deduplicated.
>
> f.e. The patch deduplicates this kind of DIE:
>
>   DW_TAG_pointer_type 
>      DW_AT_type -> ref to type DIE.
>
> To be able to deduplicate above DW_TAG_pointer_type, the patch creates a type descriptor 
> for the DIE DW_TAG_pointer_type. Any reference to the above pointer will be resolved to the
> reference to this type descriptor.
>
> There are some DIEs referencing type DIEs that should not be deduplicated.
> f.e. DW_TAG_call_site or DW_TAG_call_site_parameter. Since they are used in
> subroutines that are not moved into the "artificial type unit".
>
> Currently there is a list of such DIEs inside SyntheticTypeNameBuilder::analyzeDieForTypeName().
> DIEs handled in analyzeDieForTypeName() will be assigned a name and maybe deduplicated later.
> DW_TAG_thrown_type was missed there. Probably, instead of just a list of DIEs that might be deduplicated,
> it is possible to create a more general rule. f.e. if some DIE is a child of another DIE that is already known 
> to be deduplicated then such DIE should be considered as a deduplication candidate also. This rule should
> cover the DW_TAG_thrown_type case.
>
> Speaking of determining attributes referencing type DIEs: solution detecting type references by the type of the referenced DIE might be too expensive from the performance point of view. Resolving DIE references is quite expensive operation.

Ah, OK - I'm mostly following. Thanks for helping me understand.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96035/new/

https://reviews.llvm.org/D96035



More information about the llvm-commits mailing list