aboutsummaryrefslogtreecommitdiffstats
path: root/test/CodeGen/X86/pre-split3.ll
diff options
context:
space:
mode:
authorDuncan Sands <baldrick@free.fr>2008-10-29 06:42:19 +0000
committerDuncan Sands <baldrick@free.fr>2008-10-29 06:42:19 +0000
commit23b10f5b64e594aa7c6b415805b563fed2a75874 (patch)
treeac2eb9290783cc8dade0d031612e8c568ad79562 /test/CodeGen/X86/pre-split3.ll
parentb3bc6352defdf1a5c6b1b0770d0c4d603f6524a8 (diff)
downloadexternal_llvm-23b10f5b64e594aa7c6b415805b563fed2a75874.zip
external_llvm-23b10f5b64e594aa7c6b415805b563fed2a75874.tar.gz
external_llvm-23b10f5b64e594aa7c6b415805b563fed2a75874.tar.bz2
Fix a FIXME: in ReplaceNodeWith, if the new node
is morphed by AnalyzeNewNode into a previously processed node, and different result values of that node are remapped to values with different nodes, then we could end up using wrong values here [we were assuming that all results remap to values with the same underlying node]. This seems theoretically possible, but I don't have a testcase. The meat of the patch is in the changes to AnalyzeNewNode/AnalyzeNewValue and ReplaceNodeWith. While there, I changed names like RemapNode to RemapValue, since it really remaps values. To tell the truth, I would be much happier if we were only remapping nodes (it would simplify a bunch of logic, and allow for some cute speedups) but I haven't yet worked out how to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58372 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/CodeGen/X86/pre-split3.ll')
0 files changed, 0 insertions, 0 deletions