In Thumb1, only one variant is supported: CPS{effect} {flags}
Thumb2 supports three:
CPS{effect}.W {flags}
CPS{effect} {flags} {mode}
CPS {mode}
Canonically, .W should be used only when ambiguity is present between encodings of different width.
The wide suffix is still accepted for the latter two forms via aliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188071 91177308-0d34-0410-b5e6-96231b3b80d8
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
This reverts commit r77814.
We were sticking global constants in the .data section instead of in the
.rdata section when emitting for COFF.
This fixes PR16831.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187956 91177308-0d34-0410-b5e6-96231b3b80d8
.tbss section for zerofill thread locals. Make sure we do this
before emitting the zerofills.
Fixes PR15972.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187913 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Ana Pazos.
- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise
- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic
- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same
- Intial implementation of instruction class:
Scalar Arithmetic
- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.
- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187567 91177308-0d34-0410-b5e6-96231b3b80d8
While the .td entry is nice and all, it takes a pretty gross hack in
ARMAsmParser::ParseInstruction() because of handling of other "subs"
instructions to get it to match. Ran it by Jim Grosbach and he said it was
about what he expected to make this work given the existing code.
rdar://14214063
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187530 91177308-0d34-0410-b5e6-96231b3b80d8
32-bit symbols have "_" as global prefix, but when forming the name of
COMDAT sections this prefix is ignored. The current behavior assumes that
this prefix is always present which is not the case for 64-bit and names
are truncated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187356 91177308-0d34-0410-b5e6-96231b3b80d8
Single-slash encoded entries do not require a terminating null. This bumps
the maximum table size from ~1MB to ~9.5MB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187352 91177308-0d34-0410-b5e6-96231b3b80d8
As with the stores, these instructions can trap when the condition is false,
so they are only used for things like (cond ? x : *ptr).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187112 91177308-0d34-0410-b5e6-96231b3b80d8
These instructions are allowed to trap even if the condition is false,
so for now they are only used for "*ptr = (cond ? x : *ptr)"-style
constructs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187111 91177308-0d34-0410-b5e6-96231b3b80d8
Enable parsing all 32 floating point control registers $0-31 and stop trying to
parse floating point condition code register $fcc0. Also, return ParseFail if
the operand being parsed is not in the expected format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186861 91177308-0d34-0410-b5e6-96231b3b80d8
instructions. With this patch:
1. ldr.n is recognized as mnemonic for the short encoding
2. ldr.w is recognized as menmonic for the long encoding
3. ldr will map to either short or long encodings depending on the size of the offset
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186831 91177308-0d34-0410-b5e6-96231b3b80d8
The insn definitions themselves crept into r186689, sorry.
This should be the last of the distinct-ops instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186690 91177308-0d34-0410-b5e6-96231b3b80d8
Follows the same lines as r186686, but much more limited, since we only
use ADD LOGICAL for multi-i64 additions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186689 91177308-0d34-0410-b5e6-96231b3b80d8
The atomic tests assume the two-operand forms, so I've restricted them to z10.
Running and-01.ll, or-01.ll and xor-01.ll for z196 as well as z10 shows why
using convertToThreeAddress() is better than exposing the three-operand forms
first and then converting back to two operands where possible (which is what
I'd originally tried). Using the three-operand form first stops us from
taking advantage of NG, OG and XG for spills.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186683 91177308-0d34-0410-b5e6-96231b3b80d8
This first step just adds definitions for SLLK, SRLK and SRAK.
The next patch will actually make use of them during codegen.
insn-bad.s tests that some form of error is reported when using these
instructions on z10. More work is needed to get the "instruction requires:
distinct-ops" that we'd ideally like, so I've stubbed that part out for now.
I'll come back and make it mandatory once the necessary changes are in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186680 91177308-0d34-0410-b5e6-96231b3b80d8
Somehow forgot to git rm these two files. I believe I left the remaining
invalid* tests intentionally, though whether my reasons were sound is a
different matter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186663 91177308-0d34-0410-b5e6-96231b3b80d8
The tests were checking for barriers which the ARM ARM says they must execute
as a full system DMB/DSB, rather than that they're UNDEFINED and LLVM does in
fact represent them.
The tests happened to be passing because they were using a non-versioned ARM
triple which didn't have *any* DMB/DSB instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186662 91177308-0d34-0410-b5e6-96231b3b80d8
This allows "llvm-mc -disassemble" to accept two new features:
+ Using comma as a byte separator
+ Grouping bytes with '[' and ']' pairs.
The behaviour outside a [...] group is unchanged. But within the group once
llvm-mc encounters a true error, it stops rather than trying to resynchronise
the stream at the next byte. This is more useful for disassembly tests, where
we have an almost-instruction in mind and don't care what the misaligned
interpretation would be. Particularly if it means llvm-mc won't actually see
the next intended almost-instruction.
As a side effect, this means llvm-mc can disassemble its own -show-encoding
output if copy-pasted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186661 91177308-0d34-0410-b5e6-96231b3b80d8
