[PATCH] D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++
Guillaume Chatelet via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon May 13 07:18:55 PDT 2019
gchatelet added a comment.
In D61634#1498376 <https://reviews.llvm.org/D61634#1498376>, @efriedma wrote:
> I still think there are really two things you're trying to accomplish here, which should be handled separately.
>
> 1. Add a function attribute that works like -fno-builtin-memcpy currently does, to prevent the compiler from synthesizing calls to memcpy.
> 2. Provide a convenient way to write a small, fixed-length "memcpy", in C and in LLVM IR, that is always expanded to optimal straight-line code (without any calls or loops).
>
> These correspond to proposals (1) and (2) from your RFC; I think we need both to arrive at a reasonable final state.
>
> (The "rep; movs" is a third thing, which I think should also be handled separately, but it sounds like you don't think that's very important.)
Thank you for taking the time to comment, your feedback is highly appreciated.
I understand that your main concern is about conflating two orthogonal requirements (namely 1. and 2.) in a single attribute. Is that correct?
>From my point of view, the RFC (and this Patch) really is about 1. - because 2. can already be achieved with builtins `__builtin_memcpy(dst, src, <compile time size>)`.
My secondary goals in decreasing priority order are:
- do not change the semantic of current builtins,
- create a relatively straightforward LLVM patch that does not touch too much code and that is easy review,
- do not add more confusion around `-fno-builtin-*` meaning,
- do not add more builtins or IR intrinsics.
What is the main blocker on your end? What would you suggest so we can move forward?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61634/new/
https://reviews.llvm.org/D61634
More information about the cfe-commits
mailing list