serge-sans-paille wrote: > It's not clear to me this is actually consistently profitable if the computed > offset is small. If we have to emit a memset starting at a weird offset, the > code might get worse overall. (e.g. on x86, a memset of 32 bytes is three > instructions; a memset of 31 bytes is roughly 6.) Not sure how much we should > rely on the optimizer to fixup clean up cases like that. > > We probably need to mess with the way emitStoresForInitAfterBZero handles > padding... see #78034 . (Not directly caused by your patch, but it closely > interacts with the same code.)
I've updated the patch with a few bug fixes, and one of its noticeable effect is that it relies on the fact that padding bytes have undefined value. Especially for partial init, current clang padds to zero while with this patch leaves it undefined. With current version, I can recompile LLVM with the modified clang and have it pass its validation, so it looks rather good. I haven't sorted out the question of odd memset numbers. https://github.com/llvm/llvm-project/pull/79502 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
