[PATCH] D153453: [MemCpyOpt] implement single BB stack-move optimization which unify the static unescaped allocas

Mike Hommey via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 2 13:10:24 PDT 2023


glandium added a comment.

In D153453#4553294 <https://reviews.llvm.org/D153453#4553294>, @khei4 wrote:

> @glandium Thank you for the report! Sorry, it might take a while to reproduce it on my local. If it exists, could you share any message or crash log to suspect this patch? (I'll also appreciate it if you provide a procedure or doc to reproduce the error.)

I "suspect" this patch because I bisected the Firefox problem down to it. Revisions of llvm after the landing make Firefox crash, Revisions of llvm before don't :) The way Firefox crashes is that the rust BTreeMap code is freeing data from the stack that is not what it's supposed to be (as in, it's freeing something as a String that was never constructed as a String before)... which would probably match this message:

In D153453#4554596 <https://reviews.llvm.org/D153453#4554596>, @eaeltsin wrote:

> Heads up - we are seeing test failures that root cause to this revision.
>
> More interesting, we are seeing some of these tests failing also under AddressSanitizer, complaining about stack-use-after-scope (https://github.com/google/sanitizers/wiki/AddressSanitizerUseAfterScope) - which seems to correspond well to the topic of this change.
>
> We'll try to come up with a reproducer, but this might take time.

Presumably, a rust compiler using llvm trunk should be able to reproduce this on something smaller than Firefox.


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