[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 20:21:50 PDT 2023


khei4 added a comment.

@vitalybuka  @glandium @eaeltsin 
Thank you for reducing crashes, and reverting! I really appreciate your analysis.

> - src has no lifetime markers - so it's considered alive all the time
> - dst has lifetiem markers
>
> I guess the pass removes dst and transfer lifetimes to src, effectively reducing scope. So I would recommend to handle this case some how. In general dst lifetime can only expand src lifetime.

That means Asan has the different semantics for

  {
  lifetime.start(src)
  ...
  lifetime.end(src)
  ret void
  }

and

  {
  ...(no lifetime.start/end)
  ret void
  }

right?
I (perhaps mistakenly) think, in the case you give, src alloca lifetime seems to have not so much change, at least for the point that it's alive during the function call, but releasing by even automatic end and manual end might differ. Anyway, I'll try to repro the Asan crash and see the problem,

> BTW. Also there are cases when lifetime is not very trivial between basic block. We don't have issue with that yet, but I think it's better to bail out and don't touch if we have more then 1 start/end for source or dst, or final lifetime can not be expressed as single range.



> So the pass MUST not reduce lifetime of existing allocas - that's miscompile.
> Expanding is acceptable, but can make stack coloring or sanitizers less efficient.

Hmm, seems reasonable, it may take time, but I'll treat those! 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