llvm dev - Oct 2006 - [LLVMdev] Questions about instruction selection and instruction definitions

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
IF-THEN-ELSE flow?
> > 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
issue. 
 
> > 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,
 Roman

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

On Wed, 4 Oct 2006, Roman Levenstein wrote:
>> 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
> IF-THEN-ELSE flow?
Check out how the sparc or powerpc backends handle this.  They lower to a 
select_cc pseudo-op that expands to an if/then/else control flow.

-Chris

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

> On Wed, 4 Oct 2006, Roman Levenstein wrote:
> >> 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
> > IF-THEN-ELSE flow?
> 
> Check out how the sparc or powerpc backends handle this.  They lower
> to a 
> select_cc pseudo-op that expands to an if/then/else control flow.
Thanks! The hint about a pseudo-op was really good. After I realized
how it works, I started the implementation of SELECT_CC using this
approach. Hopefully, I can finish it today.

Chris, may be you could provide some feedback about other questions
from the original mail? In particular about the register classes and
subclasses and about restrictions related to multiclasses? I'd be very
grateful.

-Roman 
  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com