[LLVMdev] Question about porting LLVM - a single instruction op mnemonic with multiple operand forms

Villmow, Micah Micah.Villmow at amd.com
Fri Jan 21 15:18:53 PST 2011



> -----Original Message-----
> From: David A. Greene [mailto:greened at obbligato.org]
> Sent: Friday, January 21, 2011 2:59 PM
> To: Villmow, Micah
> Cc: Lu Mitnick; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Question about porting LLVM - a single
> instruction op mnemonic with multiple operand forms
> 
> "Villmow, Micah" <Micah.Villmow at amd.com> writes:
> 
> > I have this same problem in our backend. I solve it by adding a
> pseudo
> > instruction at instruction selection that transforms @R1 into R1, so
> > only a single pattern is required. I then can propogate the pseudo
> > instruction after instruction selection.
> 
> What's the rationale behind this approach?  It seems a bit clumsy to
> me.
> An instruction with varying addressing modes is not a single
> instruction.  They have different encodings, for starters.  Defining
> separate patterns for them is the "clean" LLVM approach.  I would think
> your approach adds the danger of the pseudo-instruction getting lost at
> some point.
[Villmow, Micah] It isn't that I have different addressing modes. There is
only a single instruction, but multiple different types of input arguments.
The pseudo instruction's that I use simplify the patterns by only requiring
me to write patterns for registers and not register, immediates, addresses
and any other operand type. So, instead of having to write patterns like
ADDrr, ADDri, ADDrs, etc.. for 16 different register classes, I only write
a single ADD multi-class pattern that takes only registers as inputs. I do 
luckily have another compiler that takes my output and generates a 
binary to remove any pseudo instructions. 

Micah
> 
> If the redundancy in specifying patterns for different addressing modes
> is the problem, I have some stuff to submit that helps with that.  It
> will probably take quite a bit of patch churn before it makes it to
> trunk, however.
> 
>                                -Dave






More information about the llvm-dev mailing list