Optimize performance of SIMD binary operations via polymorphic builtins #26699
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Make sure you munge the stuff (i.e. get rid of IRGenPrepare/etc) before the review starts. |
|
@gottesmm Can you elaborate why the IRGenPrepare stuff should go into IRGen directly? |
|
Is there any reason that it /shouldn't/ be in IRGen? |
| #ifndef BUILTIN_BINARY_OPERATION | ||
| #define BUILTIN_BINARY_OPERATION(Id, Name, Attrs, Overload) \ | ||
| BUILTIN(Id, Name, Attrs) | ||
| #define BUILTIN_BINARY_OPERATION(Id, Name, Attrs) BUILTIN(Id, Name, Attrs) |
There was a problem hiding this comment.
Can't we just get rid of BUILTIN_BINARY_OPERATION and use BUILTIN instead, then?
There was a problem hiding this comment.
No. Sometimes you want to #define something just for Builtin Binary Operations and not all builtins.
…TIONs. TLDR: This patch introduces a new kind of builtin, "a polymorphic builtin". One calls it like any other builtin, e.x.: ``` Builtin.generic_add(x, y) ``` but it has a contract: eventually At constant propagation time, the optimizer attempts to specialize the generic_add to the conc DISCUSSION ---------- Today there are polymorphic like instructions in LLVM-IR. Yet, at the swift and SIL level we represent these operations instead as Builtins whose names are resolved by splatting the builtin into the name. For example, adding two things in LLVM: ``` %2 = add i64 %0, %1 %2 = add <2 x i64> %0, %1 %2 = add <4 x i64> %0, %1 %2 = add <8 x i64> %0, %1 ``` Each of the add operations are done by the same polymorphic instruction. In constrast, we splat out these Builtins in swift today, i.e.: ``` let x, y: Builtin.Int32 Builtin.add_Int32(x, y) let x, y: Builtin.Vec2xInt32 Builtin.add_Vec2xInt32(x, y) ... ``` In SIL, we translate these verbatim and then IRGen just lowers them to the appropriate polymorphic instruction. Beyond being verbose, these prevent these Builtins (which need static types) from being used in polymorphic contexts. These operations in Swift look like: Builtin.add_Vec2
…ns into traps in IRGenPrepare.
…pecialize polymorphic builtins as it inlines. The reason why I am doing this is that today, the builtin concrete type specialization happens in DiagnosticConstantPropagation. This is not because of any super reason, it is just a peephole optimizer where we do stuff sort of like this (and emit diagnostics). So since we are emitting diagnostics, it makes sense to just plugin there. Sadly, this is actually /after/ predictable memory access optimizations. This means that if (without any loss of generality) we transform a generic_add to an add_Vec4xInt32 and load/store before/after the args/results of the builtin, we get unnecessary temporaries. In contrast, by teaching the SILCloner how to specialize polymorphic builtins, the specialization occurs in Mandatory Inlining, before both Predictable Memory Access Operations and DiagnosticConstantPropagation. This means that we will have a chance to eliminate any temporary stack slots improving -Onone codegen.
If the SIMD type is known to have an inner vector representation that is known by LLVM, a fast path is used to call into a polymorphic builtin operation.
nvzqz
force-pushed
the
simd_binary_ops
branch
3 times, most recently
from
1ff040a to
eb6f889
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These changes allow for expressing the vector semantics of our
SIMD{n}<T>types directly to LLVM. This is done via polymorphic builtins defined by @gottesmm. These builtins are only called for stdlib types on the condition ofSwift._isConcrete(callsBuiltin.isConcrete), which is introduced in #26466.This allows LLVM to generate efficient SIMD code in Debug builds, which may result in up to a 120x performance improvement for some operations such as addition. This also results in some performance improvements for Release builds since we no longer rely on the optimizer to auto-vectorize the loop code.
The public-facing API is only changed through underscored operations on protocols like
SIMDStorageand introduced underscored types such as_SIMDNeverand_SIMDGenericNever<T>.