[AVX512] Introduce fma3p_forms from AVX

This multiclass generates the different forms: 213, 231, 132 in AVX.

132 in AVX512 is a separate class but I am planning to use this same
multiclass to generate 231 relying on the nice the null_frag trick from AVX to
disable codegen pattern for 231.

No functionality change, no change in X86.td.expanded except for the different
instruction definition names.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220539 91177308-0d34-0410-b5e6-96231b3b80d8
[AVX512] FMA support for the 231 variants

This is asm/diasm-only support, similar to AVX.

For ISeling the register variant, they are no different from 213 other than
whether the multiplication or the addition operand is destructed.

For ISeling the memory variant, i.e. to fold a load, they are no different
than the 132 variant.  The addition operand (op3) in both cases can come from
memory.  Again the ony difference is which operand is destructed.

There could be a post-RA pass that would convert a 213 or 132 into a 231.

Part of <rdar://problem/17082571>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220540 91177308-0d34-0410-b5e6-96231b3b80d8
Make test for r220533 more robust by using GPR pattern.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220541 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Remove DwarfDebug::addScopeVariable now that it's just a trivial wrapper

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220542 91177308-0d34-0410-b5e6-96231b3b80d8