summaryrefslogtreecommitdiff
path: root/compiler/llvm/compiler_llvm.cc
diff options
context:
space:
mode:
author buzbee <buzbee@google.com> 2013-09-14 08:21:05 -0700
committer buzbee <buzbee@google.com> 2013-09-14 08:40:28 -0700
commitd0a03b8099347dee6e4bab3af95e14cd5a03b29c (patch)
tree362b8449522905e65da2e5ec443168dba3a21a0d /compiler/llvm/compiler_llvm.cc
parent11fc721de0ddadda0e57628e9c672d517f635c04 (diff)
Timely color fix
See b/10690000 For efficiency, the Quick compiler will not flush incoming register arguments to the frame if their underlying Dalvik virtual registers have been promoted to physical registers. In this case, though, there was a bug on Arm devices in that an incoming Double was promoted to physical floating point registers, but not in a usable form. The entry code generation saw that both halves of the double were promoted, but failed to check if it was in a form usable as a double. In this particular case, it meant that subsequent uses of the incoming argument referred to the uninitialized home location in the frame, resulting in garbage color values. That's the bug. Another problem is that the incoming double should never have been promoted to an unusable state in the first place - but that's merely an efficiency issue and will be addressed in another CL. Note: no good way to generate a regression test for this issue. The bug triggered because of an unusual sequence of events driving register promotion that can't easily (or robustly) be triggered from Java source. Change-Id: I7242422277193a04376461134dde71e9dec55576
Diffstat (limited to 'compiler/llvm/compiler_llvm.cc')
0 files changed, 0 insertions, 0 deletions