SILCombine: optimize creating enums with tuple payloads.

[eeckstein]

Convert sequences of

  %payload_addr = init_enum_data_addr %enum_addr
  %elem0_addr = tuple_element_addr %payload_addr, 0
  %elem1_addr = tuple_element_addr %payload_addr, 1
  ...
  store %payload0 to %elem0_addr
  store %payload1 to %elem1_addr
  ...
  inject_enum_addr %enum_addr, $EnumType.case

to

  %tuple = tuple (%payload0, %payload1, ...)
  %enum = enum $EnumType, $EnumType.case, %tuple
  store %enum to %enum_addr

Such patterns are generated for example when using the stdlib enumarated() function.

Part of rdar://problem/33438123

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci benchmark

[swift-ci]

Performance: -O

Regression	OLD	NEW	DELTA	RATIO
StringComparison_nonBMPSlowestPrenormal	1420	1540	+8.5%	0.92x (?)
Improvement	OLD	NEW	DELTA	RATIO
FlattenListLoop	4496	4140	-7.9%	1.09x (?)
ObjectiveCBridgeFromNSSetAnyObjectToStringForced	90000	84000	-6.7%	1.07x (?)

Code size: -O

Improvement	OLD	NEW	DELTA	RATIO
DictTest4Legacy.o	17180	16988	-1.1%	1.01x
DictTest4.o	16514	16338	-1.1%	1.01x

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
DictionaryBridgeToObjC_Access	782	859	+9.8%	0.91x (?)
StringComparison_slowerPrenormal	1450	1580	+9.0%	0.92x (?)
Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	5441	4919	-9.6%	1.11x (?)

Code size: -Osize

Regression	OLD	NEW	DELTA	RATIO
Hash.o	20307	20515	+1.0%	0.99x

Performance: -Onone

Regression	OLD	NEW	DELTA	RATIO
ObjectiveCBridgeStubFromNSDateRef	4400	4830	+9.8%	0.91x (?)
Improvement	OLD	NEW	DELTA	RATIO
RandomDoubleLCG	54036	49618	-8.2%	1.09x (?)

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

[slavapestov]

This looks like it’s just undoing the SILGen lowering of address only types that become loadable after specialization. We really ought to be finishing opaque values...

[davezarzycki]

Hi @eeckstein – This breaks on my Fedora 31 Linux box (x86_64). Can we revert this? Or fix it quickly?

FAIL: Swift(linux-x86_64) :: SILOptimizer/sil_combine_enums.sil (677 of 12899)
******************** TEST 'Swift(linux-x86_64) :: SILOptimizer/sil_combine_enums.sil' FAILED ********************
Script:
--
: 'RUN: at line 1';   /home/dave/b/u/t/bin/sil-opt -target x86_64-unknown-linux-gnu  -module-cache-path '/home/dave/b/u/t/swift-test-results/x86_64-unknown-linux-gnu/clang-module-cache'  -enable-sil-verify-all /home/dave/s/u/swift/test/SILOptimizer/sil_combine_enums.sil -sil-combine | '/usr/bin/python2.7' '/home/dave/s/u/swift/utils/PathSanitizingFileCheck' --sanitize BUILD_DIR='/home/dave/b/u/t/tools/swift' --sanitize SOURCE_DIR='/home/dave/s/u/swift' --use-filecheck '/home/dave/b/u/t/bin/FileCheck'  /home/dave/s/u/swift/test/SILOptimizer/sil_combine_enums.sil
--
Exit Code: 2

Command Output (stderr):
--
/home/dave/s/u/swift/test/SILOptimizer/sil_combine_enums.sil:488:82: error: expected basic block name or '}'
  %45 = init_enum_data_addr %17 : $*Optional<(Int, Int)>, #Optional.some!enumelt.1
                                                                                 ^
FileCheck error: '-' is empty.
FileCheck command line:  /home/dave/b/u/t/bin/FileCheck /home/dave/s/u/swift/test/SILOptimizer/sil_combine_enums.sil

[eeckstein]

A fix is on the way: #30526

[martinboehme]

A fix is on the way: #30526

Sorry, didn't see this previous discussion before adding the revert to #30528.

Suggestion: Whichever of #30526 and #30528 passes tests first gets merged?

[eeckstein]

@martinboehme Can we please wait until my fix (#30526) gets merged? Hopefully the linux smoke test now passes, then it should be merged soon.

[martinboehme]

Sure. I'd just like to make sure that my #30233 gets reverted either way, so that the breakage caused by it is fixed.

Once your #30526 is merged, #30528 (the revert of #30233 plus your change) can no longer be merged. I'm about to end my working day -- if you're still around for a bit, can you help make sure that my #30233 gets reverted?

[davezarzycki]

I merged #30526 to honor @eeckstein's original "test and merge" CI request and because I verified the fix locally.

[gribozavr]

Thanks everyone! I'm going to take care of reverting #30233.

[gribozavr]

I'll shepherd #30531.

[eeckstein]

Sorry for the noise and also from my side: thanks everyone!

[davezarzycki]

@eeckstein – What if any insight can you give about how this pull request passed CI before merging? Thanks!

[eeckstein]

Some SIL parsing change came in between my tests run and I merged the PR.

[eeckstein]

Though I don't know which change it was specifically.

[eeckstein]

I should have rebased and re-tested before the merge

[davezarzycki]

I wouldn't feel bad, Swift CI in general doesn't try to solve this classic race condition between pull requests:

https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use

[slavapestov]

The SIL parser change was #30499.