[LLVMdev] LLVM backend Issues

[Chris Lattner]

On Thu, 16 Nov 2006, Reid Spencer wrote:
> Here's the PDF version.

thanks

> On Thu, 2006-11-16 at 20:50 -0800, Chris Lattner wrote:
>> On Fri, 17 Nov 2006, [ks_c_5601-1987] "ÿÿ" wrote:
>>>
>>> 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
modification. Right?"

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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/