summaryrefslogtreecommitdiff
path: root/compiler/llvm/compiler_llvm.cc
diff options
context:
space:
mode:
author buzbee <buzbee@google.com> 2013-09-18 12:49:36 -0700
committer buzbee <buzbee@google.com> 2013-09-18 13:55:25 -0700
commit1fc5800def46a2fa6cbd235fcb8af099ee35a127 (patch)
tree0b0713eaec5657b789acb344154b92ae66284dd6 /compiler/llvm/compiler_llvm.cc
parentcb135ad769a5368f6ceb8caf25105a95580cbd6a (diff)
Art compiler: minor instruction assembler fix
During the assembly phase, we iteratively walk through the LIR encoding instructions until we can complete a full pass without without having to change the sequence because of displacement overflow. In the (fairly common) situation in which a 16-bit cbnz/cbz can't reach the target, we expand it to a compare and branch sequence Initially, we use a 16-bit Thumb1 unconditional branch, which itself may be expanded in a future pass to a 32-bit branch. The original cbnz/cbz LIR is converted into a cmp, and a new branch instruction is inserted following. The problem here is that by doing a following insertion, that new instruction will be the next one considered to determine if it can reach it's target. Because it is new, though, it's starting offset will show as zero - making it much more likely that it will be treated as a displacement overflow and be converted to a 32-bit branch. This is not a correctness issue - the bad offset will be corrected on the next pass, but it does result in unnecessary uses of 32-bit branches where 16-bit ones would work. Change-Id: Ie68a93fd319f0f7c603e1d870588047ad6a0779f
Diffstat (limited to 'compiler/llvm/compiler_llvm.cc')
0 files changed, 0 insertions, 0 deletions