forked from OSchip/llvm-project
66654b72c9
`MachineMemOperand` pointers attached to `MachineSDNodes` and instead have the `SelectionDAG` fully manage the memory for this array. Prior to this change, the memory management was deeply confusing here -- The way the MI was built relied on the `SelectionDAG` allocating memory for these arrays of pointers using the `MachineFunction`'s allocator so that the raw pointer to the array could be blindly copied into an eventual `MachineInstr`. This creates a hard coupling between how `MachineInstr`s allocate their array of `MachineMemOperand` pointers and how the `MachineSDNode` does. This change is motivated in large part by a change I am making to how `MachineFunction` allocates these pointers, but it seems like a layering improvement as well. This would run the risk of increasing allocations overall, but I've implemented an optimization that should avoid that by storing a single `MachineMemOperand` pointer directly instead of allocating anything. This is expected to be a net win because the vast majority of uses of these only need a single pointer. As a side-effect, this makes the API for updating a `MachineSDNode` and a `MachineInstr` reasonably different which seems nice to avoid unexpected coupling of these two layers. We can map between them, but we shouldn't be *surprised* at where that occurs. =] Differential Revision: https://reviews.llvm.org/D50680 llvm-svn: 339740 |
||
|---|---|---|
| .. | ||
| InstPrinter | ||
| MCTargetDesc | ||
| TargetInfo | ||
| CMakeLists.txt | ||
| LLVMBuild.txt | ||
| MSP430.h | ||
| MSP430.td | ||
| MSP430AsmPrinter.cpp | ||
| MSP430BranchSelector.cpp | ||
| MSP430CallingConv.td | ||
| MSP430FrameLowering.cpp | ||
| MSP430FrameLowering.h | ||
| MSP430ISelDAGToDAG.cpp | ||
| MSP430ISelLowering.cpp | ||
| MSP430ISelLowering.h | ||
| MSP430InstrFormats.td | ||
| MSP430InstrInfo.cpp | ||
| MSP430InstrInfo.h | ||
| MSP430InstrInfo.td | ||
| MSP430MCInstLower.cpp | ||
| MSP430MCInstLower.h | ||
| MSP430MachineFunctionInfo.cpp | ||
| MSP430MachineFunctionInfo.h | ||
| MSP430RegisterInfo.cpp | ||
| MSP430RegisterInfo.h | ||
| MSP430RegisterInfo.td | ||
| MSP430Subtarget.cpp | ||
| MSP430Subtarget.h | ||
| MSP430TargetMachine.cpp | ||
| MSP430TargetMachine.h | ||
| README.txt | ||
README.txt
//===---------------------------------------------------------------------===// // 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.