[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