@swift-ci test

@swift-ci benchmark

@ravikandhadai This constant-folding for string interpolation works for the DefaultStringInterpolation. It would be cool if we could also make it work for the OSLog interpolation. Any thoughts on this?

Performance: -O

Code size: -O

Performance: -Osize

Code size: -Osize

Performance: -Onone

Code size: -swiftlibs

  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: 6-Core Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

Build failed
Swift Test OS X Platform
Git Sha - 6d73e2d3c45618b4307b5f3dbe58803f297748f3

Build failed
Swift Test Linux Platform
Git Sha - 6d73e2d3c45618b4307b5f3dbe58803f297748f3

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 06e32659341cb49429fffe40d92563118b7a3d67

@ravikandhadai This constant-folding for string interpolation works for the DefaultStringInterpolation. It would be cool if we could also make it work for the OSLog interpolation. Any thoughts on this?

Making os_log use _typename would be similar to DefaultStringInterpolation implementation. It is tracked by rdar://65636690. So, I think this should enable constant fold the _typename in that case as well.

@swift-ci test

@eeckstein Just a quick question. If I understand correctly, this constant folding works for interpolation of metatypes because it is expecting the appendInterpolation function to be inlined right? So it looks like it does depend on the inlining heuristics. I am asking this as in the os_log case , the appendInterpolation implementation is slightly more complicated. So that is something I have to check.

@ravikandhadai Yes, it depends on inlining of appendInterpolation. This works because it's very simple: it's just a string append.
In case of osLog, I believe constant propagation of typeName (or constant strings in general) has to be implemented in a different way.

Note that _typeName constant propagation is done, regardless if it's in an interpolation. So even with this PR it should create a constant String argument if used in osLog.

Not propagating constant osLog string arguments is probably not so bad, because it leaves a "%s" in the format string and passes an additional argument. I think this is not so much overhead. If the argument is used in many places, it can even save some data size.

Propagation of constant String (or other) arguments could be done as a post-process, by scanning the format string and the arguments.

In the case of os_log the appendInterpolation calls take an escaping autoclosure, which gets stored in an array and later used if and only if logging is enabled. (This means that when logging is disabled for a certain log level, e.g. debug level is generally disabled outside of Xcode, the interpolated expressions are not even evaluated and the log calls are almost like noops.) But, all of this complexity is optimized away by the OSLogOptimization pass. So what remains after that pass is a chain of calls that eventually applies _typename to the interpolated meta type (which could be a constant like Int.self or a non-constant SILValue coming from the context). The chains of calls should also be optimized and inlined in -O mode and the optimization of this PR should apply eventually. This is what I would expect. But, since in the os_log case there is more interconnection between optimizations for this to happen, I am curious to know if this indeed happens.

There is a test suite that checks the combined effect of all the -O optimizations (OSLogFullOptTest.swift). The resulting LLVM IR should be similar to C os_log calls, where there are no closures, no arrays, no StringInterpolation type or appendInterpolation calls. There should only be a runtime check for whether logging is enabled or not, code to construct the argument, and a sequence of "stores" of the argument bytes into a byte buffer. @guitard0g and I are planning to add one more test suite to check if this PR's optimization will also apply and eventually we are just left with a string literal payload when interpolating constant meta types.

Note that _typeName constant propagation is done, regardless if it's in an interpolation. So even with this PR it should create a constant String argument if used in osLog.

That is right. But like here, in the os_log case also, one can just do logger.log("\(Int.self)") and _typename would be wrapped inside an appendInterpolation definition. In fact, Int.self would also be autoclosured, and _typename will apply within a closure. None of these will be evaluated until the check for whether logging is enabled passes. But, all of those closures will be optimized away because of OSLogOptimization, which essentially links the closure definition i.e., partial_applies to their use i.e., indirect calls, so that partial_apply to full_apply optimizations can completely eliminate the closure and convert it to a direct call, which followed by inlining completely eliminates the call. All of these already happen. So after all the optimization what we should be left with is conceptually an expression like _typename(Int.self) (though it is far from this to start with at the source level), so this optimization should apply and reduce it to a string literal. My only concern is that every other relevant optimization must happen before it.

Not propagating constant osLog string arguments is probably not so bad, because it leaves a "%s" in the format string and passes an additional argument. I think this is not so much overhead. If the argument is used in many places, it can even save some data size.

Yes that is right. The format string would be "%s" and there would be a payload that is a pointer (like char *) to the string's (UTF-8 encoded) bytes. But since this optimization reduces it to a string literal like "Int", ideally the payload must just be a pointer to the string literal (at the SIL level just a %ptr where %ptr = string_literal utf8 "Int"). Ideally, the creation of an intermediate Swift.String type should be completely avoided. But that may not happen as such. But, getting a pointer from a Swift.String is highly optimized at runtime due to os_log specific String SPIs.

Propagation of constant String (or other) arguments could be done as a post-process, by scanning the format string and the arguments.

Doing a post processing and combining the payload string literal into the format string is an interesting idea. It could save code size and performance. Payloads do create some boilerplate code. However, unfortunately, interpolated expressions can have an associated privacy specifier and formatting options. E.g. logger.log("\(Self.self, align: .right(columns: 10), privacy: .private))". So in such cases even if we know the static string of Self.self it would not be possible to combine it with the format string. However, it can be done when there are no privacy/formatting options, which I believe would a common case especially for meta types.

But one main problem I see with the post processing is that it the would have to happen somewhere lower in the optimization pipeline (which is where the payload may be found to be a constant), but should also have some special knowledge about os_log, especially on how to extract the format string, how to adjust the argument buffer after lifting a payload into the format string, because it requires tinkering with the headers which store the argument count and summary byte. Ideally, I would like to prevent hard coding that knowledge outside of OSLogOptimization.