[llvm-bugs] [Bug 51969] New: [NewPM][SEH] Regression due to lack of PruneEH

[via llvm-bugs]

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

            Bug ID: 51969
           Summary: [NewPM][SEH] Regression due to lack of PruneEH
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: nikita.ppv at gmail.com
                CC: aeubanks at google.com, llvm-bugs at lists.llvm.org,
                    rnk at google.com

Under the legacy pass manager, a PruneEH pass ran prior to inlining, which both
propagated nounwind and converted invokes to calls. With the new pass manager
this has been removed, on the premise that these optimizations are already
covered by PostOrderFunctionAttrs and SimplifyCFG, and there's no particular
need to perform this optimization before inlining.

There is one case where doing this before inlining is important though: If a
call of a nounwind function is inlined, then the nounwind information is lost.

This is not a problem when using the Itanium exception ABI via landingpads,
because in that case nounwind can usually be trivially inferred again -- if the
landingpad doesn't resume (but traps for example) we can determine that it is
nounwind.

However, this is not true for the SEH exception handling mechanism. The problem
there is that cleanuppads also run for asynchronous exceptions (like longjmp)
so we can't simply trap within a cleanuppad. Instead we need to use a catch-all
catchswitch, but this comes with an "unwinds to caller". This "unwind" does not
violate "nounwind" because it applies only to asynchronous exceptions, but LLVM
doesn't know that.

So I think we need to either
a) make sure that nounwind information is used before it is inlined away, e.g.
by reintroducing PruneEH, or
b) have a way to to construct a "nounwind" catchswitch -- or maybe there is one
and I'm just not aware of it?

Here is an example of the problem: https://llvm.godbolt.org/z/M1PvnYf85

-- 
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/20210925/9c520e56/attachment.html>