SILCombine: Constant-fold MemoryLayout<T>.offset(of: \.literalKeyPath)

[eeckstein]

Replace a call of the getter of AnyKeyPath._storedInlineOffset with a "constant" offset, in case of a keypath literal.
"Constant" offset means a series of struct_element_addr and tuple_element_addr instructions with a 0-pointer as base address.
These instructions can then be lowered to "real" constants in IRGen for concrete types, or to metatype offset lookups for generic or resilient types.

Replace:

  %kp = keypath ...
  %offset = apply %_storedInlineOffset_method(%kp)

with:

  %zero = integer_literal $Builtin.Word, 0
  %null_ptr = unchecked_trivial_bit_cast %zero to $Builtin.RawPointer
  %null_addr = pointer_to_address %null_ptr
  %projected_addr = struct_element_addr %null_addr
   ... // other address projections
  %offset_ptr = address_to_pointer %projected_addr
  %offset_builtin_int = unchecked_trivial_bit_cast %offset_ptr
  %offset_int = struct $Int (%offset_builtin_int)
  %offset = enum $Optional<Int>, #Optional.some!enumelt, %offset_int

rdar://problem/53309403

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci benchmark

[swift-ci]

Performance: -O

Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	5949	5351	-10.1%	1.11x (?)
ObjectiveCBridgeFromNSArrayAnyObjectForced	4660	4280	-8.2%	1.09x (?)

Code size: -O

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
String.data.LargeUnicode	123	136	+10.6%	0.90x (?)
String.data.Medium	122	133	+9.0%	0.92x (?)
Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	6874	3928	-42.9%	1.75x (?)

Code size: -Osize

Performance: -Onone

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

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 9d28786dec2131ebb5de1d799f5cbca694642658

[eeckstein]

@swift-ci smoke test linux

[jckarter]

This is clever, but it relies on undefined behavior. 0 is not a valid value for a Builtin.RawPointer. I was thinking we could do this as an IRGen lowering pass, which would let us directly replace the call with the offset computation emitted by IRGen.

[jckarter]

We should not try to optimize if the key path component refers to a resilient external property, because the property being referenced may in fact be stored. If component.getExternalDecl() returns nonnull, we should leave the call in place. It'd be good to include a test for this, where a library-evolution-enabled module exports a struct, and we validate that key paths referencing the struct's stored properties from a client module still correctly return offsets after this optimization is passed.

[eeckstein]

That's a good point.

[eeckstein]

@jckarter Hm, I would prefer to keep that as a SIL optimization. How about using a Builtin.baseAddressForOffset instead of the 0-rawpointer (which is lowered to a null pointer in IRGen)?

[jckarter]

@eeckstein That could work.

[eeckstein]

@jckarter I pushed a new version
(I created a new instruction rather than a builtin, because IMO it makes more sense).

[eeckstein]

@swift-ci smoke test

[jckarter]

Looks good, thanks!