[PATCH] D110953: [coro async] Disable lifetime.start sinking for ABI::Async and ABI::Retcon

Arnold Schwaighofer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 6 11:16:39 PDT 2021


aschwaighofer added a comment.

@lxfind What do you think, is that scenario also possible with Switch lowering. Should we disable lifetime sinking and lifetime based optimization (https://reviews.llvm.org/D110949) for switch lowering until it is fixed?

An example like the one mentioned in the commit message will fail after we have sunk the `lifetime.start` into the loop because the check whether we cross a suspend by starting at the lifetime.begin will fail leading us to use a localized alloca rather than a frame entry.

Another way of thinking about it is that by sinking the lifetime.start we are saying that the memory location is unitialized between the lifetime.start and the first write to its location (`%obj`). That is definitely not true along the path through the back-edge (other optimizations could mis-optimize based on this).

  entry:
    %obj = alloca i8
    lifetime.start(%obj)
  
    br loop
  
  loop:
    coro.suspend()
    lifetime.start(%obj)
    escape(%obj)
    cond_br %cond, label %exit, label loop
  
  exit:
    lifetime.end(%obj)

In terms of IR constrains it seems we are violating this constraint (https://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic):

> After llvm.lifetime.end is called, ‘llvm.lifetime.start’ on the stack object can be called again. The second ‘llvm.lifetime.start’ call marks the object as alive, but it does not change the address of the object.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110953/new/

https://reviews.llvm.org/D110953



More information about the llvm-commits mailing list