[build] hide some symbols in LLVMSupport

[edymtt]

Reintroduce some changes done in #23131 to hide some weak symbols
generated when compiling as part of libswiftDemangle.dylib -- doing so will avoid a performance regression.

Addresses rdar://63454568

[edymtt]

@swift-ci please test

[compnerd]

Can you explain why this is suddenly an issue? These did not change their annotation across the version, so why did they suddenly become an issue?

I think that using the SWIFT_ALWAYS_INLINE SWIFT_LIBRARY_VISIBILTIY attribute might be better if you explicitly want to annotate them. I think that the better solution is to use the correct flags. I'll put up a different change for the flags.

[edymtt]

@compnerd I've loosely based my change on the feedback I could skim from #31665 and #20633 (which were done before #31665) but I'm not sure if I've accounted for the Windows scenario correctly (or if I need a different change now)

[compnerd]

I think that a different change will be better using CMake to handle the problem. But it still doesn't explain why this wasn't an issue before.

[compnerd]

#31953 should accomplish this in a more stable and platform agnostic manner. Could you please help answer the question of why its needed and what performance regression you believe that this is causing?

[edymtt]

Sorry, replied at the same time you asked your questions.

We have some internal checks that ensure we have no weak symbol exports on dylibs, since they can cause launch time regression in applications.

To the best of my understanding, before #31665 libswiftDemangle.dylib only had a symbol reference to llvm::SmallVectorBase::grow_pod, which in was annotated with __attribute__((__weak__, __visibility__("hidden"))) in #23131, and this way we passed those checks.
With the change in #31665, now the dylib both "grabs" more (weak) symbols from llvm::SmallVectorBase and they are not hidden anymore -- triggering our checks.

Thanks a lot for #31953 -- I will study and experiment with this change.

[compnerd]

Oh! Thank you, now it all makes sense. It didn't cause a performance regression, just triggered a test case failure - one that Id argue should just be in tree.

[edymtt]

Closing this draft PR in favor of #31953 and #31955

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 941fdea

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 941fdea