[PATCH] D117250: [lld-macho] Mention string literal deduplication as a difference from ld64

[Keith Smiley via Phabricator via llvm-commits]

keith added a comment.

In D117250#3242488 <https://reviews.llvm.org/D117250#3242488>, @thevinster wrote:

> For the case of matching ld64, we always advertise (or at least try to) say on diff reviews that we should always be matching ld64's behavior. We say things like "What does ld64 produce?" or "Why isn't LLD outputting the same results as ld64". We care very much matching with ld64's behavior because that's the one of the ways we verify that LLD is working correctly. To that end, perhaps we should be matching with ld64 if we want to keep saying "LLD should be a drop-in replacement for ld64". Our current behavior clearly deviates from this, but we continue advertising this statement. On top of that, as @keith pointed out, it's fewer surprises.
>
> For the case of build speed, we also advertise that "LLD is the fastest linker to exist" (barring the existence of mold). By configuring default behaviors of LLD to achieve the fastest build speed is also aligned with that claim, but this introduces subtleties and behavioral differences that will certainly cause new users to be confused. We could enforce some that they read the documentation on the differences between ld64 and LLD, but chances are that newer folks looking to do a drop in replacement would've sunk a good amount of time debugging before consulting the manual. As @oontvoo also argues, users shouldn't be relying on linker behavior to have their code working correctly.
>
> What do I think about this? I lean towards keeping what we have today because I, more or less, agree that we should be actively fixing these issues. I'm also biased since I had to do this within our codebase as well. In the event where it can't be solved, the fallback flag does exist to offer users a way out. The way I see all this is that people adopt LLD for its speed, not because it's more correct (otherwise people would stick with ld64). If you take mold as an example, it doesn't care about backwards compatibility with older linkers. It just cares that it's the fastest linker. LLD follows the same footsteps, if not similar. QED.

My final thoughts: I think this is a good summary of us trying to achieve 2 conflicting things at the same time. My opinion for the iOS community is that prioritizing ease of onboarding (meaning ld64 compat) is more important than providing faster links out of the box (on our project specifically this flag doesn't even have a significant performance impact, so likely they'll still be faster out of the box anyways). Most of the tools at this depth of the stack are black boxes to iOS devs, but they still want improved performance, so being relatively confident they'll get the same results as ld64 is a high priority, and the chances of them diving deep enough to understand why they're not are slim if they think it introduces too much risk. On the flip side people who are deeper into this and want to optimize further won't mind adding flags if necessary. So I think prioritizing compatibility is the best way to get new users in, and then lead them to the docs so they can optimize.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117250