[PATCH] D60719: Demonstrate how to fix freestanding for memcpy
Guillaume Chatelet via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Apr 17 05:57:14 PDT 2019
gchatelet added a comment.
In D60719#1469958 <https://reviews.llvm.org/D60719#1469958>, @t.p.northover wrote:
> I think it'd be pretty unpopular with the people I know who use freestanding. They're mostly working on microcontrollers and compiling -Oz so the extra code size would be untenable; they also have memcpy implementations anyway because they use it in their own code.
> If I was trying to solve this (and I'm also not 100% sure it needs solving), I think I'd instead generate a `linkonce` definition of `memcpy` whenever it's needed and leave CodeGen unmodified.
Thx for chiming in @t.p.northover . Since the patch was mostly a proof of concept I haven't explained well what the intent was.
Ultimately I'm interested in implementing libc's mem function in C++. Let's take `memcpy` for instance, it would be composed out of fixed sized copies created from `__builtin_memcpy`. Unfortunately, the compiler is allowed to replace the intrinsic with a call to `memcpy` - which I'm currently defining - the generated code would recurse indefinitely.
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.
There are other options to explore but your comment shows that it's better to start a discussion around an RFC.
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
More information about the cfe-commits