[LLVMdev] 2-address and 3-address instructions (original) (raw)

Matthias Braun mbraun at apple.com
Fri Jul 17 15:31:38 PDT 2015

You can find a similar situation with ARM thumb2 where some instructions can be encoded in a shorter form but need to use 2-address code then. The Thumb2SizeReduce in the ARM target deals with that.

On Jul 17, 2015, at 2:03 PM, Steve King <steve at metrokings.com> wrote:

My target had the same circumstance. I found it easiest to stick with 3 operand instructions, which is LLVM's native representation anyway. You can do late conversion of SRC=DST opportunities to the compact two operand form as a post-RA peephole. Deferring conversion like this reduces the variety of instructions you have to contend with in switch statements and so on. If you also want your assembler to convert SRC=DST opportunities to the compact encoding, you can accomplish that in your AsmParser. Regards, -steve

On Fri, Jul 17, 2015 at 1:34 PM, bagel <bagel99 at gmail.com> wrote: I am writing a backend for an experimental machine that has both 2-address and 3-address versions of some instructions. The 2-address versions are more compact and thus preferred when applicable. How does one go about generating the most compact version? 1. At instruction selection, is there a predicate that can test whether one of the input sources is dead, thus allowing the selection of the 2-address version? 2. Or do I generate 2-address and have to have a custom pass that peepholes to see if a mov reg-to-reg proceeds or follows a 2-address instruction and turn it into a 3-address version? 3. Or do I generate 3-address and have a custom pass that checks if a source and destination register in a 3-address is the same and turn it into a 2-address? Anybody done this already? Thanks, Bagel

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list