[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