Here: https://godbolt.org/z/qjo5P6 st 19. 8. 2020 o 0:00 Nick Desaulniers <ndesaulniers@xxxxxxxxxx> napísal(a): > > On Tue, Aug 18, 2020 at 2:41 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > On Tue, Aug 18, 2020 at 01:58:51PM -0700, Nick Desaulniers wrote: > > > On Tue, Aug 18, 2020 at 1:27 PM Nick Desaulniers > > > <ndesaulniers@xxxxxxxxxx> wrote: > > > > > > > > On Tue, Aug 18, 2020 at 1:24 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > > > > > > > On Tue, Aug 18, 2020 at 12:13:22PM -0700, Linus Torvalds wrote: > > > > > > On Tue, Aug 18, 2020 at 12:03 PM H. Peter Anvin <hpa@xxxxxxxxx> wrote: > > > > > > > > > > > > > > I'm not saying "change the semantics", nor am I saying that playing > > > > > > > whack-a-mole *for a limited time* is unreasonable. But I would like to go back > > > > > > > to the compiler authors and get them to implement such a #pragma: "this > > > > > > > freestanding implementation *does* support *this specific library function*, > > > > > > > and you are free to call it." > > > > > > > > > > > > I'd much rather just see the library functions as builtins that always > > > > > > do the right thing (with the fallback being "just call the standard > > > > > > function"). > > > > > > > > > > > > IOW, there's nothing wrong with -ffreestanding if you then also have > > > > > > __builtin_memcpy() etc, and they do the sane compiler optimizations > > > > > > for memcpy(). > > > > > > > > > > > > What we want to avoid is the compiler making *assumptions* based on > > > > > > standard names, because we may implement some of those things > > > > > > differently. > > > > > > > > > > > > > > > > -ffreestanding as it stands today does have __builtin_memcpy and > > > > > friends. But you need to then use #define memcpy __builtin_memcpy etc, > > > > > which is messy and also doesn't fully express what you want. #pragma, or > > > > > even just allowing -fbuiltin-foo options would be useful. > > > > > > I do really like the idea of -fbuiltin-foo. For example, you'd specify: > > > > > > -ffreestanding -fbuiltin-bcmp > > > > > > as an example. `-ffreestanding` would opt you out of ALL libcall > > > optimizations, `-fbuiltin-bcmp` would then opt you back in to > > > transforms that produce bcmp. That way you're informing the compiler > > > more precisely about the environment you'd be targeting. It feels > > > symmetric to existing `-fno-` flags (clang makes -f vs -fno- pretty > > > easy when there is such symmetry). And it's already convention that > > > if you specify multiple conflicting compiler flags, then the latter > > > one specified "wins." In that sense, turning back on specific > > > libcalls after disabling the rest looks more ergonomic to me. > > > > > > Maybe Eli or David have thoughts on why that may or may not be as > > > ergonomic or possible to implement as I imagine? > > > > > > > Note that -fno-builtin-foo seems to mean slightly different things in > > clang and gcc. From experimentation, clang will neither optimize a call > > to foo, nor perform an optimization that introduces a call to foo. gcc > > will avoid optimizing calls to foo, but it can still generate new calls > > to foo while optimizing something else. Which means that > > -fno-builtin-{bcmp,stpcpy} only solves things for clang, not gcc. It's > > just that gcc doesn't seem to have implemented those optimizations. > > Can you please share some godbolt links that demonstrate these observations? > -- > Thanks, > ~Nick Desaulniers
