This patch implements initial backend support for a -mtune CPU controlled by a "tune-cpu" function attribute. If the attribute is not present X86 will use the resolved CPU from target-cpu attribute or command line.
This patch adds MC layer support a tune CPU. Each CPU now has two sets of features stored in their GenSubtargetInfo.inc tables . These features lists are passed separately to the Processor and ProcessorModel classes in tablegen. The tune list defaults to an empty list to avoid changes to non-X86. This annoyingly increases the size of static tables on all target as we now store 24 more bytes per CPU. I haven't quantified the overall impact, but I can if we're concerned.
In order to minimize code changes to non-X86 targets and out of tree targets in this initial patch. I've added a bit to the TableGen Target class to tell tablegen whether the targets supports a tune CPU. This is used to add TuneCPU as an argument to some constructors in generated files. If the target does not support a tune CPU the regular CPU is passed in place of TuneCPU in some of the lower layers.
One new test is added to X86 to show a few tuning features with mismatched tune-cpu and target-cpu/target-feature attributes to demonstrate independent control.
I have not added a -mtune to llc/opt or MC layer command line yet. With no attributes we'll just use the -mcpu for both. MC layer tools will always follow the normal CPU for tuning.
I'm happy to break this into smaller pieces if that's helpful. Maybe separating MC plumbing from X86?
This should elaborate more on what tune cpu is