Here's the PDF version.
The attached document contains the present issues I met while developing
a LLVM backend emits text assembly code for a new architecture. Most of
them are problems should be resolved.
I sincerely ask comments w.r.t these, If you have good knowledge.
In general, it's far better to ask questions in plain text email, as it makes it easier to read and respond to.
"First, all the XCC codes are being made based on SPARC LLVM backend code
(with the prefix Sparc~.*) which was already offered by LLVM developers group."
Good choice. SPARC is both complete and small, making it a good base to start with.
"In LLVM backend code for ARM (see ARMRegisterInfo.td line 15~19), there are only one kind of register, i.e. integer register. I think there might be more registers for ARM. But it seems that LLVM guys defined only the integer register in this code. (Q) Is this guess of mine correct?"
The LLVM ARM backend is not yet complete. I'm not sure of it's state, but it may just not have FP yet.
"(Q) Do I need to know exact register information for XCC such as what kinds of registers which I have to define in the code are needed, how many bits they need and so on? Or Can I just follow SPARC way"
You should be able to just define the registers, register classes, and their names. The DwarfRegNum stuff is for debug info, which you don't have to support.
"Then how about XCC? How should I define the size of integer register for XCC and sizes for other kinds of register, if there are? (Q) This part somewhat falls on the previous question. Anyway, do I need to know exact information about this from XCC architecture manual which I do not have now? Or Can I just follow SPARCs way?"
You don't need to include any encoding information at all. This information is used for a JIT, which you don't have to support.
"(Q) To resolve this problem, do I need to know exact information about whether XCC needs special instruction format from XCC architecture manual? Or Can I just follow SPARCs or ARMs way?"
You can choose to group your instructions any way you want. Grouping, classes, etc is only for factoring common stuff out of instruction patterns, it doesn't have any semantic meaning to the code generator.
"(Q) If XCC needs special instruction formats, this should be in the
instructions manual, right?"
You don't have to use instruction formats at all. This was just a convenience that makes the sparc/arm instruction descriptions shorter by factoring out common description stuff.
"(Q) I can't find where 0b000000 came from. Strange number... Please let me know."
This is described in the sparc instruction manual, which specifies how these instructions are encoded in binary form. If you plan to emit assembly, you don't need anything like this at all.
"(Q) My issue is whether I can use this code which is now implemented for
SPARC assembly code in order to compose XCC pseudo instructions through
ADJCALLSTACK instructions are used for call sequences. This is tricky, the best way to understand it is to look at examples.
"Finally, I tried to convert this code to ARM assembly code through $ llc -march=arm hello.bc -o hello.arm" HOWEVER, this makes erros as follows: ... (Q) I could make assembly codes for other targets like SPARC, X86, Native assembly ... so this error is strange to me. Please let me know the reason. "
Right, the LLVM ARM backend is not complete and the copy you have does not have enhancements that are in LLVM CVS. I suggest using a target like Sparc for comparisons.
"The part about I nstruction Pattern Stuff is shown in SparcInstrInfo.td line 43~. I tried to find this in LLVM website but didn t succeed. (Q) Would you mind telling me where I can find this information about this?"
See llvm/include/llvm/CodeGen/SelectionDAGNodes.h and related headers.