gchatelet added a comment. In D60719#1470632 <https://reviews.llvm.org/D60719#1470632>, @t.p.northover wrote:
> > IIUC freestanding environment should not rely on memcpy being present so my > > take on it was that by "fixing" freestanding I could have my cake and eat > > it too. > > The formal situation is that freestanding implementations are only required > to provide language support stuff like `va_list`. They're allowed to give > more of the standard library if they want though, as implementation defined > behaviour. > > In practice, everyone I know provides the basic `string.h` functions and the > compiler is pretty explicit about relying on them being present for > correctness. They're part of the surrounding environment a user is expected > to supply (much like the various exception handling callbacks if you want C++ > exceptions, but always required). > > For the people actually using freestanding I think they're mostly considered > important enough that they're implemented in assembly anyway so this isn't > really a burden, but... Ack. "Fixing" freestanding is not the way to go then : ) >> Ultimately I'm interested in implementing libc's mem function in C++. Let's >> take memcpy for instance > > Ah, that is an entirely different problem from what I thought you were trying > to do. In that case I'm all in favour of some solution, but would start > thinking along the lines of `-fno-builtin-memcpy` options (it's possible that > already does what you want, but can't get LLVM to form a `memcpy` from quick > tests to check). Thx for taking the time to suggest possible solution, I really appreciate it. I already tried `-fno-builtin-memcpy`. The semantic of this flag is pretty counter intuitive and I'll explain why it doesn't fit my needs. LLVM is allowed to replace a piece of code that looks like a `memcpy` with an IR intrinsic that implements the same semantic. You can see this by inspecting the IR here: https://godbolt.org/z/0y1Yqh. Now if you use `-fno-builtin-memcpy` you're preventing the compiler from understanding that this is a memory copy. Look at the IR here: https://godbolt.org/z/lnCIIh. The vectorizer kicks in in this case and the generated code is quite good but sometimes the generated code is pretty bad: https://godbolt.org/z/mHpAYe. Last but not least `-fno-builtin-memcpy`prevents the compiler from understanding code constructs as memcpy but does not prevent the compiler from generating calls to `memcpy`: - Using `__builtin_memcpy` still lowers to `@llvm.memcpy` IR intrinsics: https://godbolt.org/z/O0sjIl - Passing big structs by value will lowers to `@llvm.memcpy` IR intrinsics: https://godbolt.org/z/4BUDc0 Another solution is needed for my use case, either a new C++ intrinsics `__builtin_inline_memcpy` or an attribute that disables generated libc calls, compiler could either inline or fail with an error. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60719/new/ https://reviews.llvm.org/D60719 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
