[PATCH] D135267: [DWARF] Share across CUs only when order free

[DianQK via Phabricator via llvm-commits]

DianQK added a comment.

In D135267#3853081 <https://reviews.llvm.org/D135267#3853081>, @aprantl wrote:

> In D135267#3849760 <https://reviews.llvm.org/D135267#3849760>, @dblaikie wrote:
>
>> In D135267#3842862 <https://reviews.llvm.org/D135267#3842862>, @DianQK wrote:
>>
>>> There seems to be a lot of complexity to consider here, would adding an option to control `DINode` can be shareable be a good suggestion?
>>> Pseudo-code:
>>>
>>>   bool DwarfUnit::isShareableAcrossCUs(const DINode *D) const {
>>>     ...
>>>     return ((isa<DIType>(D) && !option("disable-die-share-across-cus"))||
>>>             (isa<DISubprogram>(D) && !cast<DISubprogram>(D)->isDefinition())) &&
>>>            !DD->generateTypeUnits();
>>>   }
>>
>> I'm not ready to understand what solutions might be appropriate as I'm still trying to understand the problem and why it arises for Swift but not C++ - sorry I haven't had enough time to try to get the context clearly in my head.
>>
>> I don't have a Swift compiler, and don't really know Swift (so I'm not sure what `Foo: Hashable` means - in C++ that would be derivation, and `Hashable` wouldn't have any reference to `Foo` (only the other way around, `Foo` would reference `Hashable`) - could you include the LLVM IR for this small example so I could take a look?
>
> `struct Foo: Equatable, Hashable {}`
>
> Is a definition of a struct with the name `Foo` that conforms to the protocols `Equatable` and `Hashable`. Protocols in Swift are //somewhat// similar in spirit to Concepts in C++. Defining `Foo` to conform to `Equatable` to //somewhat// similar to declaring `bool operator==(const Foo &) = default;` in C++. Because of the protocol conformance the compiler must emit a witness table (~ vtable) defining how to call the methods required by `Equatable` on a `Foo` object.

@aprantl is right. Thank you for your explanation.
It's not a good suggestion. I think I'm wrong, please ignore this.

By the way, I tried to fix the "no mapping for range" and "inconsistent range data" issues mentioned earlier in D136039 <https://reviews.llvm.org/D136039>.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135267