Per-function subtargets

I've been trying to understand the current state of subtargets and subtarget features in LLVM. It seems like the presence of "target-cpu" and "target-features" attributes on IR functions are currently intended to take precedence over the module-level (TargetMachine) versions. See X86TargetMachine::getSubtargetImpl for an example of this. However, this feels like it is half-way between two solutions (either all-module-wide, or all-function-specific), and some previous discussions like Redirecting to Google Groups ([LLVMdev] Embedding cpu and feature strings into IR and enabling switching subtarget on a per function basis) seem to reinforce that feeling.

Is the intent still to eventually remove the module-level subtarget options entirely? Or will the two continue to coexist? Is it up to the target to decide how to "merge" the two, or is the "all or nothing" approach the right one?

The intent is that there should be no module level attribute that
affects anything beyond ABI level decisions. The module level
attributes should control things where you cannot link two modules
together and still have an ABI conforming program. Everything else
should be on the function and such the subtarget.

Make sense?


That makes sense, but when you say "module level attribute" you mean in the IR, correct? I am asking more about the CPU and feature strings in the TargetMachine. There are are effectively (but maybe not formally) "global subtarget features" on the TargetMachine which functions lacking a "target-features" attribute inherit. This also doesn't seem to interact well with how Clang elides the attribute entirely for an empty feature string, because each target I've looked at treats the "absent" case differently than the "present but empty" case. Is removing the CPU and feature strings from the TargetMachine a goal?


Hi Scott,

That one is a little different. You'd like to be able to instantiate a
TargetMachine with a default - if nothing else it'd be hard to change
that particular API usage though it would be nice. That said, they're
just defaults for an initial subtarget. Anything on a function will
override them if you need to, but this keeps a bit more compatibility
with existing IR and use.