diff options
author | Bill Schmidt <wschmidt@linux.vnet.ibm.com> | 2014-10-21 13:02:37 +0000 |
---|---|---|
committer | Bill Schmidt <wschmidt@linux.vnet.ibm.com> | 2014-10-21 13:02:37 +0000 |
commit | 5c6cb813b6a2d36713a3e67a2aa40e220e27ede9 (patch) | |
tree | 4ee4520b932380a7270c674b94e7c6aaad6b1f61 /clang/lib/CodeGen/CodeGenFunction.h | |
parent | 6ca45c92a93feaa4c5e7bba34317b7c8b5af3125 (diff) | |
download | llvm-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