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

Hello all,

I am at the adding Instruction Set stage of adding new target support into
LLVM. There is a single instruction op mnemonic with multiple operand forms.
For example: Add R1, R2 & Add @R1, R2. I found that there is similar case in
x86 instruction set, such like ADD reg, reg & ADD mem, reg. However, the
solution of x86 is adding suffix of instruction and translating instruction
op mnemonic into ADDrr & ADDmr. I don't want to translate single
instruction
op mnemonic with different operand forms into multiple op mnemonics. I am
wondering to know whether is another solution of this problem or not?? Which
target should I look for it??

thanks a lot

yi-hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110119/de8cd4b8/attachment.html>

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.

Micah

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Lu Mitnick
Sent: Tuesday, January 18, 2011 10:29 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Question about porting LLVM - a single instruction op
mnemonic with multiple operand forms

Hello all,

I am at the adding Instruction Set stage of adding new target support into LLVM.
There is a single instruction op mnemonic with multiple operand forms. For
example: Add R1, R2 & Add @R1, R2. I found that there is similar case in x86
instruction set, such like ADD reg, reg & ADD mem, reg. However, the
solution of x86 is adding suffix of instruction and translating instruction op
mnemonic into ADDrr & ADDmr. I don't want to translate single
instruction op mnemonic with different operand forms into multiple op mnemonics.
I am wondering to know whether is another solution of this problem or not??
Which target should I look for it??

thanks a lot

yi-hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110118/4adb591a/attachment.html>

Hello Villmow,

Is it your backend EFI Byte Code Virtual Machine?? Would you mind to give me
an example about what pseudo instruction you add??

thanks a lot

yi-hong

2011/1/19 Villmow, Micah <Micah.Villmow at amd.com>
> 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.
>
>
>
> Micah
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] *On
> Behalf Of *Lu Mitnick
> *Sent:* Tuesday, January 18, 2011 10:29 AM
> *To:* llvmdev at cs.uiuc.edu
> *Subject:* [LLVMdev] Question about porting LLVM - a single instruction op
> mnemonic with multiple operand forms
>
>
>
> Hello all,
>
>
>
> I am at the adding Instruction Set stage of adding new target support into
> LLVM. There is a single instruction op mnemonic with multiple operand
forms.
> For example: Add R1, R2 & Add @R1, R2. I found that there is similar
case in
> x86 instruction set, such like ADD reg, reg & ADD mem, reg. However,
the
> solution of x86 is adding suffix of instruction and translating instruction
> op mnemonic into ADDrr & ADDmr. I don't want to translate single
instruction
> op mnemonic with different operand forms into multiple op mnemonics. I am
> wondering to know whether is another solution of this problem or not??
Which
> target should I look for it??
>
>
>
> thanks a lot
>
>
>
> yi-hong
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110119/0288d06c/attachment.html>

Hello,

Having separate instruction patterns, one per encoding, is the correct answer.
They are not the same instruction, from LLVM's perspective, even though they
share the same mnemonic. X86 is doing things the right way for this.

Consider that the instruction printing, instruction selection (isel pattern),
and binary encoding will all need to do things differently depending on the
types of the operands. Likewise, the scheduling itinerary will almost certainly
be different (memory vs. register). That's best handled by having separate
instruction definitions.

-Jim


On Jan 18, 2011, at 10:28 AM, Lu Mitnick wrote:
> Hello all,
> 
> I am at the adding Instruction Set stage of adding new target support into
LLVM. There is a single instruction op mnemonic with multiple operand forms. For
example: Add R1, R2 & Add @R1, R2. I found that there is similar case in x86
instruction set, such like ADD reg, reg & ADD mem, reg. However, the
solution of x86 is adding suffix of instruction and translating instruction op
mnemonic into ADDrr & ADDmr. I don't want to translate single
instruction op mnemonic with different operand forms into multiple op mnemonics.
I am wondering to know whether is another solution of this problem or not??
Which target should I look for it??
> 
> thanks a lot
> 
> yi-hong
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

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