Remove apparently obsolete builtin functions

[carlos4242]

Remove s_to_u_checked_conversion and u_to_s_checked_conversion functions from builtin AST parsing and generation and from SIL optimisations.

This is a quick trial PR to attempt removing what seems to be a no longer used Builtin function and to see what happens.

This arises from discussions in the Swift compiler forums:
https://forums.swift.org/t/is-this-builtin-function-now-obsolete/18244/16

As discussed ran test suite (including iOS tests). No unexpected failures occurred. However two files produce failing unit tests on SIL optimisations because they're trying to optimise SIL containing these functions so they (of course) fail. Open to suggestions as to the best way to replace/remove/update these tests? Or if they constitute a deal breaker?
test/SILOptimizer/peephole_trunc_and_ext.sil
test/SILOptimizer/sil_combine.sil

@rjmccall @jckarter @stephentyrone

p.s. There's no point running a smoke test until we agree a unit test fix, I think it will surely fail.

[carlos4242]

Example of one of the currently failing tests:

// peephole: Word(Int64(x >> 1)) -> (x >> 1)
// CHECK-LABEL: sil @_TF4test29test_trunc_u_to_s_zext_lshr_1FSuSi : $@convention(thin) (BuiltinUWord) -> BuiltinWord
// CHECK: builtin "lshr_Word"
// CHECK-NOT: builtin "zextOrBitCast_Word_Int64"
// CHECK-NOT: builtin "u_to_s_checked_conversion_Int64"
// CHECK-NOT: builtin "truncOrBitCast_Int64_Word"
// CHECK: return
// test.test_trunc_u_to_s_zext_lshr_1 (BuiltinUWord) -> Swift.BuiltinWord
sil @_TF4test29test_trunc_u_to_s_zext_lshr_1FSuSi : $@convention(thin) (BuiltinUWord) -> BuiltinWord {
bb0(%0 : $BuiltinUWord):
  debug_value %0 : $BuiltinUWord, let, name "x" // id: %1
  %2 = integer_literal $Builtin.Word, 1           // user: %7
  br bb1                                          // id: %3

bb1:                                              // Preds: bb0
  br bb2                                          // id: %4

bb2:                                              // Preds: bb1
  %6 = struct_extract %0 : $BuiltinUWord, #BuiltinUWord.value     // user: %7
  %7 = builtin "lshr_Word"(%6 : $Builtin.Word, %2 : $Builtin.Word) : $Builtin.Word // user: %8
  %8 = struct $BuiltinUWord (%7 : $Builtin.Word)  // user: %11
  br bb3                                          // id: %9

bb3:                                              // Preds: bb2
  %11 = struct_extract %8 : $BuiltinUWord, #BuiltinUWord.value    // user: %12
  %12 = builtin "zextOrBitCast_Word_Int64"(%11 : $Builtin.Word) : $Builtin.Int64 // user: %14
  %14 = builtin "u_to_s_checked_conversion_Int64"(%12 : $Builtin.Int64) : $(Builtin.Int64, Builtin.Int1) // users: %15, %16
  %15 = tuple_extract %14 : $(Builtin.Int64, Builtin.Int1), 0 // user: %18
  %16 = tuple_extract %14 : $(Builtin.Int64, Builtin.Int1), 1 // user: %17
  cond_fail %16 : $Builtin.Int1                   // id: %17
  %18 = struct $Int64 (%15 : $Builtin.Int64)      // user: %19
  %19 = struct_extract %18 : $Int64, #Int64._value // user: %21
  %21 = builtin "truncOrBitCast_Int64_Word"(%19 : $Builtin.Int64) : $Builtin.Word // user: %22
  %22 = struct $BuiltinWord (%21 : $Builtin.Word) // users: %23, %24
  debug_value %22 : $BuiltinWord, let, name "v1" // id: %23
  return %22 : $BuiltinWord                       // id: %24
}

[rjmccall]

Patch LGTM. You should just remove tests like that; they're specifically designed to test the SIL optimizer code that you've removed. I think you can just be aggressive about cutting the parts of tests that involve these builtins — we'll tell you if it looks like something you cut is actually redeemable, but the chances aren't high.

[carlos4242]

OK, @rjmccall, sounds good. I've removed the unit tests.

In my (limited) understanding of SIL Optimisations, they were all around transforms involving checked_conversion operators, combined with zext and trunc, when the expression you're working with has a known positive sign so the net result can safely be transformed to a no-op. I'm guessing this transform and these unit tests were relevant when the standard library used these operators within the implementation of some of the initialisers of the various Int types, now that's no longer the case (as I understand it)?

[carlos4242]

p.s. can someone kick off full validation tests on this, to make sure there's no regression please?

[stephentyrone]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 6933ee3

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6933ee3

[carlos4242]

Build status slightly confusing, but the later tests seemed to pass? Looks good to merge if you guys want to?

[stephentyrone]

Yes, that’s a test pass.