[libc-commits] [PATCH] D113097: [libc][NFC] Allow memcpy to be inlined

Guillaume Chatelet via Phabricator via libc-commits libc-commits at lists.llvm.org
Thu Nov 4 04:58:17 PDT 2021


gchatelet added a comment.

In D113097#3107123 <https://reviews.llvm.org/D113097#3107123>, @sivachandra wrote:

> Any reason why you have chosen `.inl` suffix instead of treating them as normal header files? IDEs and other tools are //used// to `.h` files (for example Phabricator's UI does not do syntax highlighting).

`inl`extensions are quite common. vscode highlights them correctly, Phabricator can be taught to syntax highlight them correctly (Next to the file name : `View Options` -> `Highlight as`)
I tend to use this extension when I want to convey that the content contains implementations that are to be inlined.

Now I've grepped through llvm and indeed it is not a common extension so it's probably better to use `.h` files.



================
Comment at: libc/src/string/memory_utils/memcpy_implementations.inl:37
+
+static inline void inlined_memcpy(char *__restrict dst,
+                                  const char *__restrict src, size_t count) {
----------------
sivachandra wrote:
> Nit and a question: Why give it an `inlined_` prefix which kind of implies that there is a non-inlined version somewhere? May be call it `memcpy_impl`?
I wanted to make it clear at the call site that the code will be inlined, hence the `inlined_` prefix (actually `inline_` would be better).
`memcpy_impl` is less clear in that regard, one could infer that there's going to be a call to that function.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113097/new/

https://reviews.llvm.org/D113097



More information about the libc-commits mailing list