On Thu, Oct 01, 2026 at 12:48:10PM +0200, Jason A. Donenfeld wrote: > On Thu, Oct 01, 2026 at 12:20:59PM +0200, Nathan Chancellor wrote: > > control. The change that introduced -max-store-memset only did it to > > "allow fine-tuning of the inlining threshold for performance analysis > > and optimization". If they decide to remove it for whatever reason, > > we're back to square one. > > I suppose all the more reason to get -finline-stringops=memset added to > clang. Then the dual-default thing you came up with below will naturally > start choosing the first option when it becomes available.
Fair point, I can file an issue with LLVM upstream. > > I know something like below would be uglier due to the ifdef but it > > would avoid changing anything for GCC while clearing up the issue at > > hand for clang in a guaranteed stable and succinct manner. > > But then we're back to the byte-by-byte codegen that Christophe pointed > out. I thought that was only because the fallback memset_inline() from v2 was doing a byte-by-byte initialization? With my suggested diff, nothing should change for GCC, as it does not have __builtin_memset_inline(), so the "Before the patch" code generation that Christophe showed should still be present. > > If that is not acceptable, something like the following does appear to > > work for me. > > Okay, great, let's do that. > > Does this commit seem okay with you? I used the diff you sent below and > adjusted the commit message: > https://git.zx2c4.com/linux-rng/commit/?id=56ff95ee85715047eb5b5220243778af657778c8 Yeah, that seems fine to me, thanks for taking care of it! -- Cheers, Nathan
