[SR-9425][Sema] Use derived conformance as witness when possible for == operator of raw representable enums

[LucianoPAlmeida]

There are two overloads involved in this case

• <Self where Self : Equatable> (Self.Type) -> (Self, Self) -> Bool
• <T where T : RawRepresentable, T.RawValue : Equatable> (T, T) -> Bool

Solver is finding the first one as best because the ranking rule of non-generic is better than generic.
However in CSApply https://github.com/apple/swift/blob/22506f9bdb009c0c82410406d825c87c08af7f29/lib/Sema/CSApply.cpp#L621
currently it is finding the <T where T : RawRepresentable, T.RawValue : Equatable> (T, T) -> Bool as the Equatable (WitnessChecker::findBestWitness find only this one)witness which ends up applied. What given the implementation of it:

@inlinable // trivial-implementation
public func == <T: RawRepresentable>(lhs: T, rhs: T) -> Bool
  where T.RawValue: Equatable {
  return lhs.rawValue == rhs.rawValue
}

When raw value is a String the codegen ends up with a string compare.

This PR adjusts ConformanceChecker::resolveWitnessViaLookup to not consider this witness as best match for swift raw representable enums when derive Equatable is possible(favor derived). Therefore avoiding a str compare for those cases.

Note
More details on the JIRA issue
Also, this PR although fixes the issue and makes sense to me, I'm not familiar enough with this to know if it is really the best fix.

cc @eeckstein @xedin

Resolves SR-9425, rdar://46555205

[LucianoPAlmeida]

@swift-ci Please smoke test

[LucianoPAlmeida]

@swift-ci Please smoke test

[LucianoPAlmeida]

There is a benchmark for this https://github.com/apple/swift/blob/main/benchmark/single-source/OpenClose.swift
Just curious about the impact :)

@swift-ci Please smoke benchmark

[swift-ci]

Performance: -O

Regression	OLD	NEW	DELTA	RATIO
StringFromLongWholeSubstring	4	5	+25.0%	0.80x
Improvement	OLD	NEW	DELTA	RATIO
OpenClose	108	45	-58.3%	2.40x
String.data.Medium	117	108	-7.7%	1.08x (?)
DictionaryKeysContainsCocoa	28	26	-7.1%	1.08x (?)

Code size: -O

Improvement	OLD	NEW	DELTA	RATIO
TestsUtils.o	28931	24595	-15.0%	1.18x
DriverUtils.o	129479	117847	-9.0%	1.10x
OpenClose.o	3584	3368	-6.0%	1.06x

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	4119	6783	+64.7%	0.61x (?)
FlattenListLoop	1632	2507	+53.6%	0.65x (?)
StringFromLongWholeSubstring	4	5	+25.0%	0.80x
ArrayAppendLatin1Substring	28692	31428	+9.5%	0.91x
ArrayAppendUTF16Substring	28152	30744	+9.2%	0.92x (?)
ArrayAppendAsciiSubstring	28188	30744	+9.1%	0.92x (?)
RandomShuffleLCG2	416	448	+7.7%	0.93x
Data.hash.Medium	39	42	+7.7%	0.93x
Improvement	OLD	NEW	DELTA	RATIO
OpenClose	114	48	-57.9%	2.37x
DictionaryKeysContainsCocoa	29	26	-10.3%	1.12x (?)
ProtocolDispatch	371	342	-7.8%	1.08x (?)

Code size: -Osize

Improvement	OLD	NEW	DELTA	RATIO
TestsUtils.o	23152	18513	-20.0%	1.25x
DriverUtils.o	123221	112113	-9.0%	1.10x
OpenClose.o	3629	3473	-4.3%	1.04x

Performance: -Onone

Improvement	OLD	NEW	DELTA	RATIO
OpenClose	1386	1010	-27.1%	1.37x

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

[milseman]

This has been such a long-standing perf issue. Thanks for fixing this!

[CodaFi]

@swift-ci test