in the right direction. It eliminated some hacks and will unblock codegen
work. But it's far from being done. It doesn't reject illegal expressions,
e.g. (FOO - :lower16:BAR). It also doesn't work in Thumb2 mode at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123369 91177308-0d34-0410-b5e6-96231b3b80d8
instruction based on the t_addrmode_s# mode and what it returned. There is some
obvious badness to this. In particular, it's hard to do MC-encoding when the
instruction may change out from underneath you after the t_addrmode_s# variable
is finally resolved.
The solution is to revert a long-ago change that merged the reg/reg and reg/imm
versions. There is the addition of several new addressing modes. They no longer
have extraneous operands associated with them. I.e., if it's reg/reg we don't
have to have a dummy zero immediate tacked on to the SDNode.
There are some obvious cleanups here, which will happen shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121747 91177308-0d34-0410-b5e6-96231b3b80d8
as a "long" direct branch. While the mnemonics are the same, they encode the branch offset differently, and
the Darwin assembler appears to prefer the "long" form for direct branches. Thus, in the name of bitwise
equivalence, provide encoding and fixup support for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121710 91177308-0d34-0410-b5e6-96231b3b80d8
particular, the immediate has 20-bits of value instead of 21. And bit 0 is '0'
always. Going through the BL fixup encoding was trashing the "bit 0 is '0'"
invariant.
Attempt to get the encoding at slightly more correct with this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121336 91177308-0d34-0410-b5e6-96231b3b80d8
instruction at MC lowering. Add binary encoding information for the ADR,
including fixup data for the label operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120594 91177308-0d34-0410-b5e6-96231b3b80d8
t_addrmode_s4, but with a different scaling factor.
* Encode the Thumb1 load and store instructions. This involved a bit of
refactoring (hi, Chris! :-). Some of the patterns became dead afterwards and
were removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120482 91177308-0d34-0410-b5e6-96231b3b80d8
certainly be made more generic. But it does allow us to parse something like:
ldr r3, [r2, r4]
correctly in Thumb mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120408 91177308-0d34-0410-b5e6-96231b3b80d8
The only reasonable way I could find to do this is to provide an alternate
version of the addrmode6 operand with a different encoding function. Use it
for all the VLD-dup instructions for the sake of consistency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120358 91177308-0d34-0410-b5e6-96231b3b80d8
Note: lo16AllZero remains in ARMInstrInfo.td - It can be factored out when Thumb movt is repaired.
Existing tests cover this update.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119760 91177308-0d34-0410-b5e6-96231b3b80d8
vldr.64 d1, [r0, #-32]
The problem was with how the addressing mode 5 encodes the offsets. This change
makes sure that the way offsets are handled in addressing mode 5 is consistent
throughout the MC code. It involves re-refactoring the "getAddrModeImmOpValue"
method into an "Imm12" and "addressing mode 5" version. But not to worry! The
majority of the duplicated code has been unified.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118144 91177308-0d34-0410-b5e6-96231b3b80d8
with immediates up to 16-bits in size. The same logic is applied to other LDR
encodings, e.g. VLDR, but which use a different immediate bit width (8-bits in
VLDR's case). Removing the "12" allows it to be more generic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118094 91177308-0d34-0410-b5e6-96231b3b80d8
