I’m working a project which requires assembly code for mips1 architecture for simulation purpose. I checked the latest LLVM3.2 version and found that the backend has been removed. I tried to replace the MIPS backed in LLVM3.2 by the old one in LLVM2.9 (which contains mips1) and adjust some routines to get the backend compiled. However, when llc is used to generate the assembly, there are some internal faults such as very large physical register id in the register allocation phase.
Would anyone to give me some suggestions to bring the mips1 backend to the latest LLVM version in this case? Thank you very much!
If you want to create a version for the mips1 subtarget, going back in time will probably be a lot of work for you.
If you want to modify the current version you might try the following:
1) Create a Mips1 predicate and use that to disable instruction patterns that match using non Mips1 instructions.
2) Use soft-float
3) You would need to reenable some commented out code used to implement conditional move instructions on Mips1 . You will see that in the Mips Isel lowering class.
We chose to not support Mips 1 a while back so this is about as much as I can help you on this.
Why not just use the llvm 2.9 backend and clang front end?
My guess is he wants mips1 so that he doesn't have to worry about the
patented mips instructions?
At any rate, it will be a bit of work to enable a mips1 target and I
doubt many people are interested, so it'll definitely be up to him to
do the work.
We want MIPS IV for this reason. Currently, I believe asking for mips64 gives MIPS IV (at least, I haven't found any cases where it doesn't). If this changes, then I will start adding predicates to the MIPS instructions to explicitly enable a mips4 mode, but most of the changes from MIPS IV to MIPS64 are in the FPU (vector stuff), which is already conditional, and in specifying the CP0 interface, which is relevant to operating systems but not compilers.
Using my list below, some patterns might not match now, but I think that it should mostly work.
I've read parts of the mips32 port but I've only worked on some small things in it and don't know the history of it at all.
It might be necessary to turn some things off like the branch optimization; I did not work on that so I don't know what instructions it uses and if any are non Mips I.
But it should be possible to resurrect any needed code.
The biggest piece is the code which handles the lack of a conditional move instruction in mips I. That code is commented out still (not used any more) but he would still need to go back into the svn/git in order to see how to enable that. (I have something similar to that in the mips16 port because mips16
also lacks conditional move).
This way, the assembler he's using will tell him if he still has non mips I instructions being emitted.
This is probably not a trivial task for someone that does not know the mips32 port.