[llvm-dev] Empty TokenIdentifier and multiple patterns for an instruction

Nemanja Ivanovic via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 27 12:46:46 PST 2017

1. Anonymous patterns are generally used for clarity and convenience. You
can certainly define a list of patterns in the definition of the
instruction, but it's often much clearer and easier to read to provide
multiple patterns with anonymous patterns. Another thing this allows you to
do is predicate the patterns - different anonymous patterns enclosed in
different predicate blocks are useful. Also, you don't have to have a 1:1
mapping of input pattern to instruction when writing anonymous patterns -
something like this is fine `def : Pat<(i32 (input_pattern i32:$in1,
i32:$in2)), (i32 (INSTR1 $in1, (INSTR2 (INSTR3 $in3))))>;`. Something like
that is obviously much harder to write in the definition of either of the 3
2. See 1 above. I imagine there is something that is different between the
two. Perhaps the input/output operands in the patterns. Also, you can
produce multiple definitions that are synonyms with some differences in
operands, register classes, etc. - see uses of `isCodeGenOnly`.

On Mon, Nov 27, 2017 at 12:33 PM, Liad Mordekoviz via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello,
> I come with 2 questions:
> 1. I’ve seen in multiple places the use of “def : some class<>” and can’t
> find any information about that anywhere,
> Why would I declare a nameless def?
> 2. I’d like to create 2 patterns to be replaces with the same def, for
> example:
> def ADD : MyInstClass<0x10, "add", add>;
> def ADD : MyInstClass<0x10, "add", adde>;
> (I’m trying to add support to add with carry)
> Thank you very much!
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171127/fc4da152/attachment.html>

More information about the llvm-dev mailing list