aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/VirtualFileSystem.cpp
diff options
context:
space:
mode:
authorCraig Topper <craig.topper@intel.com>2019-02-23 21:41:44 +0000
committerCraig Topper <craig.topper@intel.com>2019-02-23 21:41:44 +0000
commitdc185522fbdec75490cacfaa15966c4a2a7505d2 (patch)
treeceeb05f7c9270cd0f28e5cf9e6de583982f417d2 /llvm/lib/Support/VirtualFileSystem.cpp
parentbe9eeb552678f4aaa7293f43dc4d0881cdf5df3a (diff)
downloadllvm-dc185522fbdec75490cacfaa15966c4a2a7505d2.zip
llvm-dc185522fbdec75490cacfaa15966c4a2a7505d2.tar.gz
llvm-dc185522fbdec75490cacfaa15966c4a2a7505d2.tar.bz2
[TwoAddressInstructionPass] After commuting an instruction and before trying to look for more commutable operands, resample the number of operands.
The new instruciton might have less operands than the original instruction. If we don't resample, the next loop iteration might read an operand that doesn't exist. X86 can commute blends to movss/movsd which reduces from 4 operands to 3. This happened in the test case that caused r354363 & company to be reverted. A reduced version of that has been committed here. Really this whole checking for more commutable operands is a little fragile. It assumes that the new instructions operands are the same order and positions as the original except for the pair that was swapped. I don't know of anything that breaks this assumption today, but I've left a fixme. Fixing this will likely require an interface change. llvm-svn: 354738
Diffstat (limited to 'llvm/lib/Support/VirtualFileSystem.cpp')
0 files changed, 0 insertions, 0 deletions