[all-commits] [llvm/llvm-project] 4cd3f4: [WebAssembly] Fix a bug in finding matching EH pad

Heejin Ahn via All-commits all-commits at lists.llvm.org
Thu May 28 19:48:12 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 4cd3f4b31b0bd19f3b63f53888a5a2afea68e109
      https://github.com/llvm/llvm-project/commit/4cd3f4b31b0bd19f3b63f53888a5a2afea68e109
  Author: Heejin Ahn <aheejin at gmail.com>
  Date:   2020-05-28 (Thu, 28 May 2020)

  Changed paths:
    M llvm/lib/Target/WebAssembly/WebAssemblyLateEHPrepare.cpp
    M llvm/test/CodeGen/WebAssembly/exception.ll

  Log Message:
  -----------
  [WebAssembly] Fix a bug in finding matching EH pad

Summary:
`getMatchingEHPad()` in LateEHPrepare is a function to find the nearest
EH pad that dominates the given instruction. This intends to be
lightweight so it does not use full WebAssemblyException scope analysis
or dominator analysis. It simply does backward BFS to its predecessors
and stops at the first EH pad each search path encounters. All search
should end up at the same EH pad, and if not, it returns null.

But it didn't take into account that when there are inner scopes within
the current scope, some path in BFS can hit an inner EH pad first. For
example, in the given diagram, `Inst` belongs to the outer scope and
`getMathingEHPad()` should return 'EHPad 1', but some search path can go
into the inner scope and end up with 'EHPad 2'. The search will return
null because different paths end up with different EH pads.
```
--- EHPad 1 ---
| - EHPad 2 - |
| |         | |
| ----------- |
|   Inst      |
---------------
```

So far this was OK because we haven't tested a case in which a given
instruction is far from its EH pad. Also, this bug does not happen when
the inner EH scope is a cleanup scope, because a cleanup scope ends with
a `cleanupret` whose successor is an EH pad, so the search encounters
that EH pad first before going into the child scope. But this can happen
when the child scope is a catch scope that ends with `catchret`. So this
patch, when doing backward BFS, does not search predecessors that ends
with `catchret`. Because `catchret`s are replaced with `br`s during this
pass, this records BBs that have `catchret`s in the beginning, before
doing any other transformations.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D80571




More information about the All-commits mailing list