diff options
| author | Sanjay Patel <spatel@rotateright.com> | 2015-02-17 20:08:21 +0000 |
|---|---|---|
| committer | Sanjay Patel <spatel@rotateright.com> | 2015-02-17 20:08:21 +0000 |
| commit | b811c1d6a57beae697be440144b9f8b8b33e0605 (patch) | |
| tree | 249a0045df268a18224ea5052220b26ab54084b5 /llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | |
| parent | 127b6c3ba7fef9c0b39dac4c343d14eeba2c53d2 (diff) | |
| download | llvm-b811c1d6a57beae697be440144b9f8b8b33e0605.zip llvm-b811c1d6a57beae697be440144b9f8b8b33e0605.tar.gz llvm-b811c1d6a57beae697be440144b9f8b8b33e0605.tar.bz2 | |
prevent folding a scalar FP load into a packed logical FP instruction (PR22371)
Change the memory operands in sse12_fp_packed_scalar_logical_alias from scalars to vectors.
That's what the hardware packed logical FP instructions define: 128-bit memory operands.
There are no scalar versions of these instructions...because this is x86.
Generating the wrong code (folding a scalar load into a 128-bit load) is still possible
using the peephole optimization pass and the load folding tables. We won't completely
solve this bug until we either fix the lowering in fabs/fneg/fcopysign and any other
places where scalar FP logic is created or fix the load folding in foldMemoryOperandImpl()
to make sure it isn't changing the size of the load.
Differential Revision: http://reviews.llvm.org/D7474
llvm-svn: 229531
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp')
0 files changed, 0 insertions, 0 deletions