You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
codegen: Unify printing of and add some more internal IR validity errors (#58429)
What should codegen do when it detects invalid IR? There are a few
reasonable options. One is to just assert - this is relatively
straightforward but also not very friendly because it immediately takes
down your session, so you can't inspect what values may have caused the
issue. Additionally, often allow invalid IR in dead code (because
otherwise transformation passes would have to check whether the
transformation that they're doing makes some code dead, which can be
expensive or not necessarily visible).
Thus we generally try to keep codegen going, trying to bail back to
valid code as quickly as possible. In a few places, we additionally
insert an unmodeled `emit_error("Internal Error")`. These are a bit
weird because the earlier stages of the compiler do not know that they
can exist, but in practice they mostly work fine (although they can
cause additional crashes if there are try/catches in the way). If we
don't, then we generally just stop codegening, so if execution ever were
to reach there, it'll just run into whatever code comes after, likely
crashing fairly soon.
Because of this consideration, the `emit_error` is generally preferred.
However, the tradeoff is that it increases the size of the code and LLVM
can no longer optimize under the assumption that a particular code
branch doesn't happen. We thus need to be judicious in where we use it.
The general guidance is that it's fine to use in situations where the IR
itself is obviously invalid, but should not be arbitrarily added to all
instances of `unreachable` (putting behind NDEBUG is fine).
This PR cleans this up a bit by changing all these error locations to
print `INTERNAL ERROR - IR Validity`, as well as adding a new one to
`emit_invoke` when there's a manifest mismatch in type of the arguments
and the signature. This new case is particularly useful after the recent
addition of ABIOverride, as that makes it more likely that external
AbstractInterpreters are doing ABI shenanigans.
0 commit comments