When an operand class is defined with MIOperandInfo set to a list of
suboperands, the AsmMatcher has so far required that operand to also define
a custom ParserMatchClass, and InstAlias patterns have not been able to
set the individual suboperands separately. This patch removes both of those
restrictions. If a "compound" operand does not override the default
ParserMatchClass, then the AsmMatcher will now parse its suboperands
separately. If an InstAlias operand has the same class as the corresponding
compound operand, then it will be handled as before; but if that check fails,
TableGen will now try to match up a sequence of InstAlias operands with the
corresponding suboperands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124314 91177308-0d34-0410-b5e6-96231b3b80d8
This will be used to check patterns referencing a forthcoming
INSERT_SUBVECTOR SDNode. INSERT_SUBVECTOR in turn is very useful for
matching to VINSERTF128 instructions and complements the already
existing EXTRACT_SUBVECTOR SDNode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124145 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, while this is the "right" thing to do, it breaks some ARM
asm parsing tests because MemMode5 and ThumbMemModeReg are ambiguous. This
is tricky to resolve since neither is a subset of the other.
XFAIL the test for now. The old way was broken in other ways, just ways
we didn't happen to be testing, and our ARM asm parsing is going to require
significant revisiting at a later point anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123786 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed to allow an InstAlias for an instruction with an "OptionalDef"
result register (like ARM's cc_out) where you want to set the optional register
to reg0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123490 91177308-0d34-0410-b5e6-96231b3b80d8
the symbolic immediate names used for these instructions, fixing their pretty-printers, and
adding proper encoding information for them.
With this, we can properly pretty-print and encode assembly like:
mrc p15, #0, r3, c13, c0, #3
Fixes <rdar://problem/8857858>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123404 91177308-0d34-0410-b5e6-96231b3b80d8
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
being tested. This ensures that we test the tools just built and not
some random tools that might happen to be in the user's PATH. This
makes LLVM testing much more stable and predictable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122341 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't currently used for anything but I ran into it when experimenting
with some changes, and it might be useful in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121911 91177308-0d34-0410-b5e6-96231b3b80d8
Some quad-register intrinsics with lane operands only take a double-register
operand for the vector containing the lane. The valid range of lane numbers
is then half as big as you would expect from the quad-register type.
Note: This currently has no effect because those intrinsics are now handled
entirely in the header file using __builtin_shufflevector, which does its own
range checking, but I want to use this for generating tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121867 91177308-0d34-0410-b5e6-96231b3b80d8
