[LLVMdev] Questions about instruction selection and instruction definitions

[Rafael Espíndola]

On 10/3/06, Roman Levenstein <romixlev at yahoo.com> wrote:
> Hi,
>
> Few more questions that I found while trying to develop a new backend.
> And sorry if I ask too many questions.

I only have answers to some of them:

> 1) My target (embedded processor, which is a "not so direct" successor
> of Z80 family of processors) does not support SELECT, so I was looking
> for a workaround.
>
> First I was thinking about expanding it into conditional flow with
> branching, but then I have found that there exists a pass called
> LowerSelect already.
>
> I added in the getAnalysisUsage of my DAGtoDAGSel class (derived from
> SelectionDAGSel) as a required analysis. After that, there are no more
> SELECT instructions passed to my code selector, which is what I wanted.
> Is it a correct to do it this way?
You can add the line
setOperationAction(ISD::SELECT, MVT::i32, Expand);
to the constructor of you TargetLowering class. See the current
backend for an example.

....

> On my target, there are many instructions that have certain constraints
> using register subclasses, for example:
>   loads from memory are only allowed to the GR_ regs
>   copies between GR and GR_ regs are allowed
>   stores to memory are only possible from GR_ regs
>
> How this can be expressed in the definitions of instructions? I tried
> to use GR_ register classes at appropriate places, when describing
> instructions operands. Is it a right method?  So far I was not very
> successful, since after I did it as I described, tblgen started to
> produce errors like "Pattern x is impossible to select". Why do I have
> it and what should it mean? May be I'm doing something wrong.
I think that using register classes is the right solution. I don't
know what is causing the problem.

> Besides what I described, my target has additionally support for banks
> if registers. Access to the registers in the non-current bank is more
> expensive than access to regs from the current bank. And many
> operations cannot have such regs from other banks as first operand. How
> something like this can be expressed? Is there any support for such
> kind of constraints. I can roughly imagine how instruction descriptions
> could look like. But I guess also a register allocator should take this
> into account. Otherwise too many copies between regs from current bank
> and other banks will be generated (e.g. virtual reg was allocated to a
> physical register from another bank, but later it is required in an
> instruction that cannot take this register as operand. So, it must be
> copied into a register in the current bank...). And decisions of
> register allocator need to be based on minimization of total costs,
> probably. Sounds very complex. I just wonder if LLVM already supports
> something like this in any form.
I don't know, but you can implement a register allocator that is
specific to this problem.

> 3) My target has only 2 addr instructions, i.e. each instruction has at
> most 2 operands. Do I still need to use 3 operands for such operations
> like OR, AND, ADD, SUB in my instruction descriptions, but mark them as
> isTwoAddrress=1??? Or do I need to call a special pass that converts
> everything into 2-operand instructions?
Using isTwoAddrress=1 should do it.

> Thanks,
>  Roman

Best Regards,
Rafael