Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Reduce array abstraction on apple platforms dealing with literals #13665
Part of the ongoing quest to reduce swift array literal abstraction
Introduce a new classify_bridge_object SIL instruction to handle the
This also introduces a couple of SIL combines for patterns that occur
This is the same as PR13659 but rebased on top of master.
1 similar comment
I realize that the motivation for this may not be entirely obvious. The point of this is to allow the SIL optimizer to reason about the magic bits that are mangled into the Builtin.BridgeObject values, instead of having them be extracted with and's of magic constants that are unknown to the optimizer (only IRGen does and should have access to this info). Here is one example of a before and after this patch:
I recognize that it is theoretically possible that lazy bridging will go away. However, until and if that happens, we should take this patch and continue providing more abstraction for the bridge representation.
2 similar comments
very nice! In general lgtm.
some comments: I think it makes sense to clean up Builtin.swift a bit - to use the new builtin and remove some functions/variables which are not needed anymore now.
It would be nice to get rid of the bridge_object_to_word instruction at all. But afaik, it is still needed at least for getting spare bits out of the array buffer pointer (the needsElementTypeCheck flag). Either we extend classify_bridge_object returns to return this spare bit as well or we'll add another instruction. But we can do this in a follow-up work.
Jan 2, 2018
We would like to keep around a way to get the raw payload of a BridgeObject with the trivial bit set. For the case of String in particular we'd use that ability for small string optimization. If we have to change
On Jan 2, 2018, at 6:41 PM, John McCall ***@***.***> wrote: @rjmccall commented on this pull request. In docs/SIL.rst: > @@ -4617,6 +4617,19 @@ pointer_to_thin_function TODO +classify_bridge_object +`````````````````````` +:: + + sil-instruction ::= 'classify_bridge_object' sil-operand + + %1 = classify_bridge_object %0 : $Builtin.BridgeObject + // %1 will be of type (Builtin.Int1, Builtin.Int1) I'd be interested to know what you feel is broken about multi-result instructions. I tried several different designs and concluded that there are just inherent trade-offs that have to be made here. I chose to make working with single-result instructions easier at the cost of adding boilerplate to multi-result instructions. If you have a concrete alternative design in mind, I'd love to hear it.
Also, we added a helper mixin to make it really easy to define one. It is something like 10 lines of code.…
— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub, or mute the thread.