[LLVMbugs] [Bug 2157] New: Filter expressions could (should?) be removed from LLVM exception handling

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=2157

           Summary: Filter expressions could (should?) be removed from LLVM
                    exception handling
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Since we are currently eliminating magic semantics from LLVM's
exception handling, how about eliminating filters?  The unwinder
allows for two ways of comparing an exception with a list of
typeinfos (typeinfos correspond to classes in C++): (a) does the
exception match a typeinfo in the list, or (the opposite) (b)
does the exception fail to match any typeinfo in the list?  Case
(b) is the filter case, case (a) is the selector case.

Note how case (b) can be implemented using case (a): just
invert the result!  And in fact when I started working on
exception handling, one of the first things I did was to
eliminate filters and only make use of selectors.  However
it didn't work because in C++ filters have a magic property
(reminiscent of must-not-throw regions, which can be thought
of as a filter with an empty list of typeinfos): if the handler
for a filter throws an exception, the runtime checks whether
the new exception fails to match the filter, and if so calls
terminate (this should sound familiar to anyone who followed
the recent 'nounwind' saga).

So I'm proposing eliminating filters, and instead implementing
them using selectors and explicit extra invoke+terminate code,
eliminating this magic property.  This would be a conceptual
simplification of LLVM exception handling.

There are some disadvantages: due to the way dwarf eh actually
works, it is more efficient to use a filter than to use a
selector and inverting the result, because "inverting the
result" requires performing comparing N comparisons where N
is the number of typeinfos, while using a filter only needs
one.  Also, this will increase code size.  Note that all of
this only matters for C++ which I think is the only user of
filters right now.

On the other hand, we could try to mitigate these problems
at codegen time by identifying code sequences which could
be realized by a filter entry in the dwarf tables, i.e. by
auto-generating filters from selectors.  I'm afraid that this
seems much harder than PR2154, probably requiring heroic
optimization.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.