hoy added a comment.
> (Also, can the backend safely optimize an `invoke` to a `linkonce_odr` > function that's `nounwind` to a `call`? I thought it couldn't, in case the > function is de-refined to a version that's not `nounwind`. But the frontend > can do it since it has access to the source and knows it can't be de-refined > in that way?) Can you please elaborate what de-refining does? The backend does have the ability to optimize a `nounwind` invoke and its landing pad into a single call instruction. > In any case, let's say the backend can do this optimization. > > I wonder if this is just a single example, where there could be various other > (header-related) peepholes that cause similar problems for stable output. > IIRC, the usual Clang approach is to make as-close-to-optimal IR up front, > but maybe in some situations it's desirable to delay optimizations to improve > stability. Another application where that could be useful is caching. > Maybe the high level principle deserves a broader discussion on the forums. > Do we want IRGen to prefer stable IR, or optimized IR? Should there be a -cc1 > flag to decide (which AutoFDO could set)? A flag to allow for a stable IR generation would be nice, but I guess in general we do not want to lose the opportunity that are only available to the front end just to favor AutoFDO. The current case sounds to me a very specific case that the backend can also get, and so far it's the only case we have see affecting the IR stability so I'm inclined to just deferring it to the backend. WDYT? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83906/new/ https://reviews.llvm.org/D83906 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
