[PATCH] D83906: [CodeGen] Emit a call instruction instead of an invoke if the called llvm function is marked nounwind

Hongtao Yu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 8 20:58:05 PST 2023


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



More information about the cfe-commits mailing list