llvm-6502/lib/Target/MSP430
Chandler Carruth 283b399377 [Modules] Make Support/Debug.h modular. This requires it to not change
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.

This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:

- Header files that need to provide a DEBUG_TYPE for some inline code
  can do so by defining the macro before their inline code and undef-ing
  it afterward so the macro does not escape.

- We no longer have rampant ODR violations due to including headers with
  different DEBUG_TYPE definitions. This may be mostly an academic
  violation today, but with modules these types of violations are easy
  to check for and potentially very relevant.

Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.

The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206822 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-21 22:55:11 +00:00
..
InstPrinter
MCTargetDesc
TargetInfo
CMakeLists.txt
LLVMBuild.txt
Makefile
MSP430.h
MSP430.td
MSP430AsmPrinter.cpp
MSP430BranchSelector.cpp
MSP430CallingConv.td
MSP430FrameLowering.cpp
MSP430FrameLowering.h
MSP430InstrFormats.td
MSP430InstrInfo.cpp
MSP430InstrInfo.h
MSP430InstrInfo.td
MSP430ISelDAGToDAG.cpp [Modules] Make Support/Debug.h modular. This requires it to not change 2014-04-21 22:55:11 +00:00
MSP430ISelLowering.cpp
MSP430ISelLowering.h
MSP430MachineFunctionInfo.cpp
MSP430MachineFunctionInfo.h
MSP430MCInstLower.cpp
MSP430MCInstLower.h
MSP430RegisterInfo.cpp
MSP430RegisterInfo.h
MSP430RegisterInfo.td
MSP430SelectionDAGInfo.cpp
MSP430SelectionDAGInfo.h
MSP430Subtarget.cpp [Modules] Make Support/Debug.h modular. This requires it to not change 2014-04-21 22:55:11 +00:00
MSP430Subtarget.h
MSP430TargetMachine.cpp
MSP430TargetMachine.h
README.txt

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

DISCLAIMER: Thid 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.