tree 5fdec32d947ce5f8898f827619b159e349886188
parent c4b27bbf5e193ebff1e6131e90e8c82add996684
author Cherry Zhang <cherryyz@google.com> 1560784292 -0400
committer Cherry Zhang <cherryyz@google.com> 1560975175 +0000

gollvm: use implicit nil checks

Previously, because of the lack of non-call exceptions in LLVM,
we always generate explicit nil checks, which is inefficient.
This CL switches to implicit nil checks.

We do this by using the LLVM "ImplicitNullChecks" mechanism
(https://llvm.org/docs/FaultMaps.html). It pattern-matches the
nil check control flow, and rewrites it to an implicit control
flow where the branch is removed, and the potentially faulting
instruction's PC is recorded in a table, along with the "if-nil"
block's PC. The pass runs very late (it is a machine-IR pass),
so removing the branch will not cause any more reordering.

We don't use the ImplicitNullChecks pass directly, because the
pass will crash with some input (which appears to me related to
passing structs by value). Instead, we add a modified copy of the
pass.

To integrate with our runtime, we don't use LLVM's Fault Maps
section. Instead, we generate exception table entries for the
potentially faulting instructions, so the seg fault generated at
that instruction can be caught by Go's recover mechanism.

We don't remove the nil checks in the frontend. The nil check
threshold we pass to the frontend is still -1. Otherwise without
the branches the backend will reorder stores across a potentially
faulting instruction.

Change-Id: I8adeadfd864b9d3668960e0ffb545a36fc250834
Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/182578
Reviewed-by: Than McIntosh <thanm@google.com>