mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-01 16:33:37 +01:00
8a77999240
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.
llvm-svn: 117054
33 lines
1.9 KiB
Plaintext
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.
|