SILOptimizer: add a pass to perform target specific constant folding.

[eeckstein]

The TargetConstantFolding pass performs constant folding for target-specific values:

  MemoryLayout<T>.size
  MemoryLayout<T>.alignment
  MemoryLayout<T>.stride

Constant folding those expressions in the middle of the SIL pipeline enables other optimizations to e.g. allow such expressions in statically allocated global variables (done by the GlobalOpt pass).

The implementation requires to create a temporary IRGenModule, which is used to get actual constant sizes/alignments from IRGen's type lowering.

rdar://94831524

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci benchmark

[eeckstein]

@swift-ci test

[atrick]

I'm in favor of this optimization, but I want to understand why our policy on .swiftmodule target information can suddenly be reversed. I mean, it would have been great to do this 7 years ago.

It seems like it should be decided on the forum whether .swiftmodules can embed target information... there are driver implications.

#if arch has already been decided one way or the other, but can the target triple or codegen options also affect .swiftmodule?

Is it ok to serialize target info as long as we're limited only to SizeOf/AlignOf/StrideOf? Can we embed any target info as long as it is hashed as part of the SILModule's compiler info string? What target info is currently included in that string?

It would be nice to decouple client build options as much as possible from module build options. That could avoid confusion reproducing issues and/or unnecessary .swiftmodule rebuilds. But, if all the target information is already embedded in the module, then we might as well be using it in the optimizer!

I always imagined that target information would be strictly limited to the "Lowered" SIL stage, and that we would not allow Lowered SIL to be serialized. So we at least preserve some notion of target-independent SIL modules. (We don't currently enter Lowered SIL soon enough, but we could plan to do that.) But, again, if any change to IRGenOptions forces a .swiftmodule rebuild then there's no point worrying about this at all.

[atrick]

The file header needs comments.

I would expect SIL passes to be in /SILOptimizer/Transforms regardless of their dependency on target information. IRGen is really a separate subsystem with 150 source files of its own!

If we wanted to respect library dependencies and have some conceptual layering, then we would split IRGen/TypeInfo into a separate ABI abstraction, independent of LLVM IR generation. You would have something like int ABI::TypeInfo::getStaticSize(). Since that's too much work, we can just include /IRGen headers from /SILOptimizer.

[atrick]

value = value.sextOrTrunc(intTy->getGreatestWidth());

It seems a little strange that you silently handle possible truncation. I'm looking for either a bailout on actual truncation, or an assertion that reextending the truncated value yields back the original number.

[eeckstein]

I want to understand why our policy on .swiftmodule target information can suddenly be reversed.

This pass runs after serialization. So there is no change in swiftmodule files.
But it's a good point. I'll add an assert+comment to make this clear.

we can just include /IRGen headers from /SILOptimizer.

Fine with me. I think it makes sense to add a new sub-directory in SILOptimizer for such optimizations, e.g. IRGenTransforms. I'll move the source file there.

It seems a little strange that you silently handle possible truncation.

That's what IRGen does if those builtins are not constant folded. But yes, it makes sense to be on the safe side. I'll add a check.