aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenFunction.h
diff options
context:
space:
mode:
authorBill Schmidt <wschmidt@linux.vnet.ibm.com>2014-10-21 13:02:37 +0000
committerBill Schmidt <wschmidt@linux.vnet.ibm.com>2014-10-21 13:02:37 +0000
commit5c6cb813b6a2d36713a3e67a2aa40e220e27ede9 (patch)
tree4ee4520b932380a7270c674b94e7c6aaad6b1f61 /clang/lib/CodeGen/CodeGenFunction.h
parent6ca45c92a93feaa4c5e7bba34317b7c8b5af3125 (diff)
downloadllvm-5c6cb813b6a2d36713a3e67a2aa40e220e27ede9.zip
llvm-5c6cb813b6a2d36713a3e67a2aa40e220e27ede9.tar.gz
llvm-5c6cb813b6a2d36713a3e67a2aa40e220e27ede9.tar.bz2
[PowerPC] Avoid VSX FMA mutate when killed product reg = addend reg
With VSX enabled, test/CodeGen/PowerPC/recipest.ll exposes a bug in the FMA mutation pass. If we have a situation where a killed product register is the same register as the FMA target, such as: %vreg5<def,tied1> = XSNMSUBADP %vreg5<tied0>, %vreg11, %vreg5, %RM<imp-use>; VSFRC:%vreg5 F8RC:%vreg11 then the substitution makes no sense. We end up getting a crash when we try to extend the interval associated with the killed product register, as there is already a live range for %vreg5 there. This patch just disables the mutation under those circumstances. Since recipest.ll generates different code with VMX enabled, I've modified that test to use -mattr=-vsx. I've borrowed the code from that test that exposed the bug and placed it in fma-mutate.ll, where it tests several mutation opportunities including the "bad" one. llvm-svn: 220290
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.h')
0 files changed, 0 insertions, 0 deletions