[Swift+WASM] [IRGen] Disable COMDAT for reflection metadata

[zhuowei]

LLVM's Wasm COMDAT code assumes each COMDAT will be in its own section. This works for C++ on Clang, since each COMDAT is emitted into its own .rodata. section, but not for Swift metadata, which are all placed in the same section.

Disable COMDAT support when emitting reflection metadata.

This matches the behaviour on ELF (where COMDATs are disabled) and MachO (which doesn't support COMDAT)

This shouldn't affect existing platforms.

---

@ddunbar @MaxDesiatov This avoids an LLVM assert when building stdlib for WebAssembly: should be helpful for SR-9307.

@compnerd: You added the COMDAT support originally for Windows/COFF, right? Should the check for COMDAT support use a whitelist instead of a blacklist, since ELF, MachO, and now WASM all disabled it?

[compnerd]

This feels wrong. The reason that ELF is disabling it is because of a bug in gold, it should be enabled otherwise. This is a size issue.

Why does this not work on WASM? It should - the sections are coalesced (.rodata.* -> .rodata). The same should occur with the metadata.

[zhuowei]

@compnerd As I mentioned, WASM only supports comdats with section coalescing: Swift emits all the metadata of a certain type together in the same section, not in individual sections, so LLVM asserts with a cannot rename symbol name error because the comdat code always tries to start a new section when encountering comdat.

You can get this to happen in C++ as well: https://gist.github.com/zhuowei/597b77698634aac9b302d43b5c464838

Edit: Would emitting each comdat in its own section work? I haven't tried that; is it worth trying?

[compnerd]

Yes, they should be in unique section names (see how -ffunction-sections -fdata-sections work in ELF). That should work just fine, and would be better IMO.

[CodaFi]

@zhuowei Are you still pursuing this?

[MaxDesiatov]

He doesn't, at least to my knowledge. I can pick it up, but it would make sense to do that in a separate PR probably, so feel free to close this one.