Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-11660] Umbrella: function multiversioning and dispatch on CPU features #54069

Open
stephentyrone opened this issue Oct 23, 2019 · 0 comments
Assignees
Labels
compiler The Swift compiler in itself new feature standard library Area: Standard library umbrella

Comments

@stephentyrone
Copy link
Member

Previous ID SR-11660
Radar None
Original Reporter @stephentyrone
Type New Feature
Additional Detail from JIRA
Votes 7
Component/s Compiler, Standard Library
Labels New Feature
Assignee @stephentyrone
Priority Medium

md5: b35212867b34a993cbeb9f33d729dd13

Issue Description:

(This is a umbrella bug covering several pieces of work across different components of Swift)

Swift does not currently have much support for taking advantage of CPU features (we don't even build an x86_64h slice of the standard library on macOS). It is possible to compile a module with specific features enabled, via an arcane and undiscoverable incantation:

-Xcc -Xclang -Xcc -target-feature -Xcc -Xclang -Xcc +avx2

but this is not something that we can recommend to users in good faith, and operates at the wrong granularity for must use, anyway.

A very rough outline of a plan (which will surely not withstand contact with reality):

  1. 1. Design a source-level function attribute similar to clang and GCC's attribute((target("OPTIONS"))) that allows one to specify that a function is to be compiled with specific target options enabled. This should (I think) change the name mangling, to support having multiple versions of a function for different subtargets. It should propagate onto anything that gets inlined into the current function (but should not propagate in the other direction). This feature should allow you to tag a function with multiple sets of CPU features to use (e.g. I should be able to specify that single source function gets compiled with +avx2+fma, +avx512f+avx512vl, and +avx512vnni).

  2. Add a runtime info object to the standard library that provides a common denominator of information about CPU features, cache sizes, portably across OSes. (Hard questions that I'm punting on: what is this "common denominator" and what do we do in a heterogeneous environment. See, e.g. a hilarious bug where Samsung packaged cores with 64B and 128B cachelines together. Hopefully people know not to do that, but it will happen again.)

  3. When a function is called that has multiple implementations available, we should, either by default or when indicated by some source annotation, use the information from this struct to dispatch to the appropriate implementation at the call site. The interaction of this with code size is subtle--CPU features often let us use less code, but the dispatch itself can increase size if it isn't done right.

  4. Consider auto-generating dyld resolvers (Apple platforms) and ifuncs (linux) for versioned functions that are dylib symbols. We don't really want people to write these things themselves because they're easy to screw up and the set of operations you're actually allowed to use in them becomes quite restrictive as you move down the system).

This is all very rough, and I expect to add more to it over time. This is just a stick in the sand to point to and a place to collect more thoughts on the subject.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself new feature standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

1 participant