After browsing through the source and test suite, it seems that using -Xcc -Xclang is how one tunes the micro-architectural behavior of Swift code? For example: test/IRGen/function-target-features.swift
Is this correct? Is there a better way? Are there bugs tracking the addition of flags to swiftc?
That works? I would’ve expected that to do nothing since that will only impact the clang importer. You would need to use the undocumented flags in LLVM through -Xllvm I would imagine.
-Xllvm flags are compiled out of Release builds, since they impact startup time. -Xcc -Xclang will probably work because swiftc uses Clang to set up the LLVM IR module, but it's relying on undocumented behavior. (-Xclang flags are just as unstable as -Xfrontend flags for Swift.) What is stable are the -target-cpu and -target-variant driver flags, but I don't remember what they're hooked up to.
Sounds like we're missing both a defined model and some tests, at the least =) Some of this may be an OK starter bug candidate.
I can't find -target-variant anywhere in the source or tests.
It's also unfortunate that -Xllvm gets compiled out. As far as I can tell, that's the only way to control whether vzeroupper gets splatted into code that doesn't need it (i.e. -Xllvm -x86-use-vzeroupper=0).
I can file bugs if people want, but honestly, this problem space is large and ugly. All one needs to do is look at the mess of flags that has accumulated over the years in clang or gcc to support obscure features of various targets. For example, gcc has 1596 machine dependent flags, and only 14.5% of those nominally overlap.
The cpu feature flags are relatively reasonable (+fma, etc). The tuning flags are more of a mess. Feature flags would be a good start, and I think the "right" thing to do is more clear in that space (we also should have feature attributes on functions in some form, eventually).
It's important to disentangle "tune for this uArch" and "enable these ISA instructions", though. These are fundamentally two different things, and the confusion between them is responsible for a lot of the current mess in gcc and clang.