StringOptimization: optimize interpolated C strings. #38274
Conversation
Optimize code like:
puts("\(String.self)")
Optimizing string interpolation and optimizing C-strings are both done in StringOptimization.
A second run of the StringOptimization is needed in the pipeline to optimize such code, because the result of the interpolation-optimization must be cleaned up so that the C-String optimization can kick in.
Also, StringOptimization must handle struct_extract(struct(literal)), where the struct_extract may be in a called function.
To solve a phase ordering problem with inlining String semantics and inlining the `String(stringInterpolation: DefaultStringInterpolation)` constructor, we do a simple analysis of the callee. Doing this simple "interprocedural" analysis avoids relying on inlining that String constructor.
rdar://74941849
|
@swift-ci test |
|
@swift-ci benchmark |
Performance (x86_64): -O
Code size: -OPerformance (x86_64): -Osize
Code size: -OsizePerformance (x86_64): -Onone
Code size: -swiftlibsHow to read the dataThe 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 Noise: Sometimes the performance results (not code size!) contain false Hardware Overview |
| auto *si = dyn_cast<StructInst>(value); | ||
| if (!si) | ||
| return StringInfo::unknown(); | ||
| value = si->getFieldValue(field); |
There was a problem hiding this comment.
Looks like we are directly forwarding the value of the result of the callee after the pattern match. Just wondering does it work in cases where there could be a runtime failure (eg. cond_fail) in the callee's entry block before the return ?
There was a problem hiding this comment.
this is no problem. The call is not eliminated. It's just following SSA-values.
| // exposed once optimized String interpolations (from the high-level string | ||
| // optimization) are cleaned up. But before the mid-level inliner inlines | ||
| // semantic calls. | ||
| P.addStringOptimization(); |
There was a problem hiding this comment.
What type of clean up is required ? Is this something that can be implemented in InstSimplifier in the future, so that we don't need another instance of the pass here ?
There was a problem hiding this comment.
All kind of function passes (e.g. SILMem2Reg) are needed to cleanup the code produced by the first StringOptimization.
Of course, we could put all optimizations in SILCombine, but that would defeat the purpose of having separate passes for separate optimizations. It's a design decision.
|
Build failed before running benchmark. |
|
Build failed |
|
Build failed |
Optimize code like:
Optimizing string interpolation and optimizing C-strings are both done in StringOptimization.
A second run of the StringOptimization is needed in the pipeline to optimize such code, because the result of the interpolation-optimization must be cleaned up so that the C-String optimization can kick in.
Also, StringOptimization must handle
struct_extract(struct(literal)), where the struct_extract may be in a called function.To solve a phase ordering problem with inlining String semantics and inlining the
String(stringInterpolation: DefaultStringInterpolation)constructor, we do a simple analysis of the callee. Doing this simple "interprocedural" analysis avoids relying on inlining that String constructor.rdar://79723829