mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-30 17:33:24 +00:00
e921f32353
The long encoding for Thumb2 unconditional branches is broken. Additionally, there is no range checking for target operands; as such for instructions originating in assembly code, only short Thumb encodings are generated, regardless of the bitsize needed for the offset. Adding range checking is non trivial due to the representation of Thumb branch instructions. There is no true difference between conditional and unconditional branches in terms of operands and syntax - even unconditional branches have a predicate which is expected to match that of the IT block they are in. Yet, the encodings and the permitted size of the offset differ. Due to this, for any mnemonic there are really 4 encodings to choose for. The problem cannot be handled in the parser alone or by manipulating td files. Because the parser builds first a set of match candidates and then checks them one by one, whatever tablegen-only solution might be found will ultimately be dependent of the parser's evaluation order. What's worse is that due to the fact that all branches have the same syntax and the same kinds of operands, that order is governed by the lexicographical ordering of the names of operand classes... To circumvent all this, any necessary disambiguation is added to the instruction validation pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188067 91177308-0d34-0410-b5e6-96231b3b80d8
13 lines
467 B
ArmAsm
13 lines
467 B
ArmAsm
@ RUN: llvm-mc -triple=thumbv7-apple-darwin -mcpu=cortex-a8 -show-encoding < %s | FileCheck %s
|
|
.syntax unified
|
|
.globl _func
|
|
.thumb_func _foo
|
|
.space 0x37c6
|
|
_foo:
|
|
@------------------------------------------------------------------------------
|
|
@ B (thumb2 b.w encoding T4) rdar://12585795
|
|
@------------------------------------------------------------------------------
|
|
b.w 0x3680c
|
|
|
|
@ CHECK: b.w #223244 @ encoding: [0x36,0xf0,0x06,0xbc]
|