[llvm-bugs] [Bug 45296] New: [missed optimization] LLVM leaves behind no-op lifetime.end cleanup

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45296

            Bug ID: 45296
           Summary: [missed optimization] LLVM leaves behind no-op
                    lifetime.end cleanup
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Transformation Utilities
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvm-bugs at lists.llvm.org

Seems related to issue 44329

Consider:

$ cat t.cpp
struct NoopDtor { ~NoopDtor() {} };
void mayThrow(NoopDtor *);
void hasCleanup() {
  NoopDtor o;
  mayThrow(&o);
}

$ clang -S -O2 t.cpp  -emit-llvm -o - | grep -A3 -E 'invoke|landingpad'
  invoke void @_Z8mayThrowP8NoopDtor(%struct.NoopDtor* nonnull %o)
          to label %invoke.cont unwind label %lpad

invoke.cont:                                      ; preds = %entry
  call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull %0) #3
  ret void

--
  %1 = landingpad { i8*, i32 }
          cleanup
  call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull %0) #3
  resume { i8*, i32 } %1

In this example, SROA is unable to remove the alloca for `o`, so the
lifetime.end remains in the landingpad cleanup. If we do not escape `o`, some
mid-level pass can remove the landingpad (I'm guessing PruneEH). We should
teach this pass to look past lifetime.end, and other meta instructions (assume,
etc).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200324/b38d7d33/attachment-0001.html>