diff options
author | Wesley Peck <peckw@wesleypeck.com> | 2010-12-09 03:42:04 +0000 |
---|---|---|
committer | Wesley Peck <peckw@wesleypeck.com> | 2010-12-09 03:42:04 +0000 |
commit | 8397be042766f1913ceaa2b3e6782de0322bbe6a (patch) | |
tree | c9a36c534fb1fc85287eedf1e15bb4452c401334 /lib/Target/MBlaze/TODO | |
parent | 6b0fa635d5bfd80940e667cec1662e611f5d270f (diff) |
Reworking the stack layout generated by the MBlaze backend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121355 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Target/MBlaze/TODO')
-rw-r--r-- | lib/Target/MBlaze/TODO | 16 |
1 files changed, 0 insertions, 16 deletions
diff --git a/lib/Target/MBlaze/TODO b/lib/Target/MBlaze/TODO index cc0aa48288..2e613eb0ca 100644 --- a/lib/Target/MBlaze/TODO +++ b/lib/Target/MBlaze/TODO @@ -1,30 +1,14 @@ * Writing out ELF files is close to working but the following needs to be examined more closely: - - 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. - Look at the MBlazeGenFastISel.inc stuff and make use of it |