hubert.reinterpretcast added a comment. In D150221#4351249 <https://reviews.llvm.org/D150221#4351249>, @rjmccall wrote:
> Force-emitting every `static` in the translation unit can be very expensive; > there are a lot of headers that declare all their constants as `static > const`. And removing dead globals is a pretty important optimization, e.g. > to eliminate the string literals used by assertions that the compiler was > able to fold to `true`. So I don't think it's unreasonable for us to ask > whether we should just be naively adding this option instead of figuring out > a more targeted way of satisfying these users. Seeing as there are application developers paying the cost of--and relying on at least some aspects of--this behaviour, I am looking to see how they can move to Clang with less migration overhead. It seems to me that more targeted ways to solve the issue would require that the application developers apply a mechanism to select variables for this treatment. That involves a trade-off for them between performance and uptime-friendly serviceability. If they don't have an analysis to make those decisions, then having a more complicated tunable interface does not help them. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150221/new/ https://reviews.llvm.org/D150221 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
