llvm-6502/lib/Target/MBlaze/TODO
Wesley Peck 4da992aeba Adding initial AsmParser implementation for the MBlaze backend. It is
mostly based on the ARM AsmParser at this time and is not particularly
functional.

Changed the MBlaze data layout from:
    "E-p:32:32-i8:8:8-i16:16:16-i64:32:32-f64:32:32-v64:32:32-v128:32:32-n32"
to:
    "E-p:32:32:32-i8:8:8-i16:16:16"
because the MicroBlaze doesn't have i64, f64, v64, or v128 data types.

Cleaned up the MBlaze source code:
    1. The floating point register class has been removed. The
       MicroBlaze does not have floating point registers. Floating
       point values are simply stored in integer registers.
    2. Renaming the CPURegs register class to GPR to reflect the
       standard naming.
    3. Removing a lot of stale code from AsmPrinter after
       the conversion to InstPrinter.
    4. Simplified sign extended loads by marking them as
       expanded in ISelLowering.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117054 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-21 19:48:38 +00:00

33 lines
1.9 KiB
Plaintext

* Writing out ELF files is close to working but the following needs to
be examined more closely:
- ELF files are written with the wrong E_MACHINE value because
ELFObjectWriter::WriteHeader function does not yet support
target specific E_MACHINE values.
- ELF relocation records are incorrect because the function
ELFObjectWriter::RecordRelocation is hard coded for X86/X86-64.
- Relocations use 2-byte / 4-byte to terminology in reference to
the size of the immediate value being changed. The Xilinx
terminology seems to be (???) 4-byte / 8-byte in reference
to the number of bytes of instructions that are being changed.
- BRLID and like instructions are always assumed to use a 4-byte
immediate value for the relocation and BEQID and like instructions
are always assumed to use a 2-byte immediate value for the relocation.
I think this means that conditional branches like BEQID can only
branch += 32768 bytes (~8192 instructions). We should allow conditional
branches to use 4-byte relocations but I'm not sure how to do that
right now.
- Relocation records for indirect calls are not being generated
correctly. These should emit and IMM 0 directly before the ORI
instruction that loads the register (just like when a BRLID
instruction is used instead of an ORI).
* Code generation seems to work relatively well now but the following
needs to be examined more closely:
- The stack layout needs to be examined to make sure it meets
the standard, especially in regards to var arg functions.
- The delay slot filler is ad hoc but seems to work. Load and
store instructions were prevented from being moved to delay
slots but I'm not sure that is necessary.
- The processor itineraries are copied from a different backend
and need to be updated to model the MicroBlaze correctly.