[PATCH] D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++

Guillaume Chatelet via Phabricator via llvm-commits llvm-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 llvm-commits mailing list