[LLVMdev] Operand order in dag pattern matching in td files

[Anitha B Gollamudi]

On 16 November 2012 14:05, Craig Topper <craig.topper at gmail.com> wrote:
> You've unfortunately chosen a complex example.
>
> Your second question is needs be answered first. null_frag causes the
> pattern to be dropped.
>
> Now having covered that the reason the operands are in the order they are is
> because the only instruction that doesn't use null_frag is this one
>
> defm r213 : fma3s_rm<opc213, !strconcat(OpStr, !strconcat("213", PackTy)),
>                      x86memop, RC, OpVT, mem_frag, OpNode>
>
> Which specifies the operand order as 213 thus why they are 2, 1, 3 in the
> pattern.
>

Thanks. I get it. Looking into DAGCombiner and X86ISelLowering made it
more clear.

I am just wondering if there is any reason why only "213" form of FMA
is supported. Is it more of an initial support? Clearly it impacts
performance negatively when "231" or "132" forms are required (due to
the store/move of operands).

-Anitha