diff options
| author | Wesley Peck <peckw@wesleypeck.com> | 2010-10-21 03:57:26 +0000 |
|---|---|---|
| committer | Wesley Peck <peckw@wesleypeck.com> | 2010-10-21 03:57:26 +0000 |
| commit | 4e9141fd4c0040cd7d4d830211f7d27fd98e9338 (patch) | |
| tree | d5abec1ba09eba300463f04139a22d89ad425518 /lib/Target/MBlaze/TODO | |
| parent | 5b7a825ec5551fd1dff8c9f280cc203da3fdedd9 (diff) | |
| download | llvm-4e9141fd4c0040cd7d4d830211f7d27fd98e9338.tar.gz llvm-4e9141fd4c0040cd7d4d830211f7d27fd98e9338.tar.bz2 llvm-4e9141fd4c0040cd7d4d830211f7d27fd98e9338.tar.xz | |
Recommit 116986 with capitalization typo fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116993 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Target/MBlaze/TODO')
| -rw-r--r-- | lib/Target/MBlaze/TODO | 26 |
1 files changed, 26 insertions, 0 deletions
diff --git a/lib/Target/MBlaze/TODO b/lib/Target/MBlaze/TODO new file mode 100644 index 0000000000..737f111c63 --- /dev/null +++ b/lib/Target/MBlaze/TODO @@ -0,0 +1,26 @@ +* 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. + +* 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. |