[PATCH] D153453: [MemCpyOpt] implement single BB stack-move optimization which unify the static unescaped allocas
Kohei Asano via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Aug 2 23:30:00 PDT 2023
khei4 added a comment.
In D153453#4556368 <https://reviews.llvm.org/D153453#4556368>, @vitalybuka wrote:
> Not sure what you asking.
> Lifetime intrinsics are optional. if they are omitted, alloca is valid from entry to any return. So asan, if no markers, can not detect use after scope, if the is markers, it will complain on any alloca access after the end marker.
>
> Reproducer is probably oversimplified. In real miscompile case after the end, inserted by D153453 <https://reviews.llvm.org/D153453> transformation, there was use of the src alloca. Which was valid when we have no markers, but invalid now, because it's after the end.
>
> I've update the reproducer df0b1df99c9ccf110482661678321e596566c725 <https://reviews.llvm.org/rGdf0b1df99c9ccf110482661678321e596566c725>.
@vitalybuka
Thanks! The case you give makes it clear! (Sorry, my words were misreading, I referred to your reproducers, and you answered me clearly :)
Actually, the use after the end is problematic, and this patch introduces lifetime.end for `%agg.tmp3.sroa.35.128.sroa_idx,`, and other optimization seems to lift the contiguous memcpy src, which causes use after lifetime.end.
Although the patch may be on that optimization, I'll handle that! thanks!
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D153453/new/
https://reviews.llvm.org/D153453
More information about the llvm-commits
mailing list