Craig Topper c7a0b2684f [X86][MC][Target] Initial backend support a tune CPU to support -mtune
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.

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. Another new test is added to demonstrate that the scheduler model follows the tune CPU.

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.

Differential Revision: https://reviews.llvm.org/D85165
2020-08-14 15:31:50 -07:00
..

//===---------------------------------------------------------------------===//
// MSP430 backend.
//===---------------------------------------------------------------------===//

DISCLAIMER: This backend should be considered as highly experimental. I never
seen nor worked with this MCU, all information was gathered from datasheet
only. The original intention of making this backend was to write documentation
of form "How to write backend for dummies" :) Thes notes hopefully will be
available pretty soon.

Some things are incomplete / not implemented yet (this list surely is not
complete as well):

1. Verify, how stuff is handling implicit zext with 8 bit operands (this might
be modelled currently in improper way - should we need to mark the superreg as
def for every 8 bit instruction?).

2. Libcalls: multiplication, division, remainder. Note, that calling convention
for libcalls is incomptible with calling convention of libcalls of msp430-gcc
(these cannot be used though due to license restriction).

3. Implement multiplication / division by constant (dag combiner hook?).

4. Implement non-constant shifts.

5. Implement varargs stuff.

6. Verify and fix (if needed) how's stuff playing with i32 / i64.

7. Implement floating point stuff (softfp?)

8. Implement instruction encoding for (possible) direct code emission in the
future.

9. Since almost all instructions set flags - implement brcond / select in better
way (currently they emit explicit comparison).

10. Handle imm in comparisons in better way (see comment in MSP430InstrInfo.td)

11. Implement hooks for better memory op folding, etc.