rsmith added a comment. In D88712#2325823 <https://reviews.llvm.org/D88712#2325823>, @MaskRay wrote:
> In D88712#2324105 <https://reviews.llvm.org/D88712#2324105>, @rsmith wrote: > >> What are the expected semantics in this case? Is this: >> >> - the function is still the builtin, but if it ends up being a libcall, call >> a function with a different asm name, or >> - the function is not considered to be the builtin any more, or >> - something else? >> >> I think this patch is approximately the first thing, but it's also cutting >> off emission for cases where we wouldn't emit a libcall. Should we make that >> distinction? > > Yes, we do the first one. I mentioned the limitation in the description. This > happens with some functions like `abs` which clang has customized emit > without using a library call. What should happen for a case where the LLVM mid-level optimizers insert a libcall (for example, inventing a call to `memcpy`), and `memcpy` was renamed at the source level to another name? Do we still call the original name? Generally I wonder if we should instead be renaming the function in LLVM's `TargetLibraryInfo`, rather than getting the frontend to try to set up a situation where LLVM is unlikely to generate a call to the "wrong" name for the builtin. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88712/new/ https://reviews.llvm.org/D88712 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
