SIL Verifier now enabled in non-asserts builds behind -sil-verify-all

Over the past bit there have been some discussions around enabling asserts by default: Compiler performance overhead of assertions and SIL verifier.

In that post I pushed back since I think the overhead is too much and I suggested instead a different model: allow for verifiers to be triggered by frontend flags in no-assert builds and invest in the driver learning how to re-run failed compilations with those extra frontend flags. This would give us most of the benefits of having an asserts compiler without having any overhead along the normal path.

That being said, I wanted to put my actions where my words had said they would be and show the possibility of the approach, so I implemented: [sil-optimizer] Compile in SIL verifiers when NDEBUG is enabled and enable them only when -sil-verify-all is enabled. by gottesmm · Pull Request #35558 · apple/swift · GitHub. In this PR, I changed the SILVerifier to now be compiled into non-asserts builds, but only perform verification if -sil-verify-all is passed in. So along the normal path of compilation, there will not be any overhead, but if one passed in -sil-verify-all, one will get verification after each pass.

Keep in mind this is just the first step along the way. I am starting to look a little at the driver to see how difficult it will be the implement the re-running functionality, but with some pointers from @typesanitizer I think I will be able to do it... stay tuned!

@typesanitizer @dan-zheng @tbkka @Andrew_Trick @Erik_Eckstein

9 Likes

For the swift compiler, there's no question in my mind that verification, along with most asserts, should at least be available in the release build. The only questions is: what should be enabled by default and how different kinds of checks and individual asserts be exposed or suppressed. I think a mechanism for suppressing asserts will be needed before they can be usefully enabled by default.