[LLVMdev] Questions about instruction selection and instruction definitions

Roman Levenstein romixlev at yahoo.com
Wed Oct 4 05:57:24 PDT 2006

Hi Rafael,

Thanks for the answers.

> > 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.

I actually tried it first. But then if, I remember correctly, SELECT
nodes were expanded into something using SELECT_CC, which is also not
supported on my target. Basically, only conditional branches are
supported. Therefore I thought about using the LowerSelect pass. But
I'll try again this evening. May be I was doing something wrong. 

What should be the result of expanding SELECT?  Some sort of

> > 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.

I also think so. But when you get such a message like described above,
it is rather difficult to guess the reason. I even extended the tblgen
tool to print a whole set of conflicting patterns in this case. But
they all looked OK for me, i.e. I could not see any clear reason why a
given pattern  would not be selected. I'll try to dig deeper into this
> > 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.

Sure. I just thought that there may be some sort of initial support for
that kind of issues.
Best regards,

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the llvm-dev mailing list