InstAlias<{alias}, {aliasee}>;
The InstAlias instruction should be able to go from the MCInst to the
{alias}. All of the information is there to match the MCInst with the
{aliasee}. From there, it's a simple matter to emit the {alias}, with the
correct operands from the {aliasee}.
The code this patch generates can be used by the InstPrinter to automatically
print out the alias without having to write special C++ code to handle the
situation.
This is a WIP, and therefore are several limitations. For instance, it cannot
handle AsmOperands at the moment. It also doesn't know what to do when two
{alias}es match the same {aliasee}. (Currently, it just ignores those two cases
and allows the printInstruction method to handle them.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126538 91177308-0d34-0410-b5e6-96231b3b80d8
--force-configure to force running configure before building.
--extra-llvm-config-flags
--extra-llvm-gcc-config-flags
--extra-gcc-config-flags
Pass additional argument to the various configure invocations.
This also eliminates a default build flavor because explicitly
specifying builds could result in build flavors being run repeatedly.
Finally, turn off fortran builds for the moment because install
appears to be broken.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126510 91177308-0d34-0410-b5e6-96231b3b80d8
bot. I am not sure if this is valid Valgrind exclusion file syntax, but the
Internet seems to think so.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126051 91177308-0d34-0410-b5e6-96231b3b80d8
A major part of its (eventual) goal is to support a much cleaner separation between disassembly callbacks
provided by the target and the disassembler emitter itself, i.e. not requiring hardcoding of knowledge in tblgen
like the existing disassembly emitters do.
The hope is that some day this will allow us to replace the existing non-Thumb ARM disassembler and remove
some of the hacks the old one introduced to tblgen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125966 91177308-0d34-0410-b5e6-96231b3b80d8
FIXME: It does not improve MSVC's issue.
[Danil Malyshev] Defining PRINTF_EXPONENT_DIGITS env is the suggested way to make MinGW ANSI/POSIX compatible. This is not only about the case we are discussing, but in general, I'd like to have explicitly defined compatibility mode for all the tests running on MinGW.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125725 91177308-0d34-0410-b5e6-96231b3b80d8
- Add custom operand matching for imod and iflags.
- Rename SplitMnemonicAndCC to SplitMnemonic since it splits more than CC
from mnemonic.
- While adding ".w" as an operand, don't change "Head" to avoid passing the
wrong mnemonic to ParseOperand.
- Add asm parser tests.
- Add disassembler tests just to make sure it can catch all cps versions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125489 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the AsmMatcher handling to distinguish between an error custom-parsing
an operand and a failure to match. The former should propogate the error
upwards, while the latter should continue attempting to parse with
alternative matchers.
Update the ARM asm parser accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125426 91177308-0d34-0410-b5e6-96231b3b80d8
When matching operands for a candidate opcode match in the auto-generated
AsmMatcher, check each operand against the expected operand match class.
Previously, operands were classified independently of the opcode being
handled, which led to difficulties when operand match classes were
more complicated than simple subclass relationships.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125245 91177308-0d34-0410-b5e6-96231b3b80d8
an annoyance of mine when working on tests: if the input .ll file
is broken, opt outputs an error and generates an empty file. FileCheck
then emits its "ooh I couldn't find the first CHECK line, scanning
from ..." which obfuscates the actual problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125193 91177308-0d34-0410-b5e6-96231b3b80d8
It seeks tools(eg. [cmp, grep, sed]) in same directory, to be sane.
It seeks "bash" only in the directory found at last time. Or bash would be insane (against other tools).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125175 91177308-0d34-0410-b5e6-96231b3b80d8
checkToolsPath(dir,tools):
return True if "dir" contains all "tools".
whichTools(tools,paths):
return a directory that contains all "tools" in "paths".
Or return None when all "tools" were not met.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125174 91177308-0d34-0410-b5e6-96231b3b80d8
Motivation: Improve the parsing of not usual (different from registers or
immediates) operand forms.
This commit implements only the generic support. The ARM specific modifications
will come next.
A table like the one below is autogenerated for every instruction
containing a 'ParserMethod' in its AsmOperandClass
static const OperandMatchEntry OperandMatchTable[20] = {
/* Mnemonic, Operand List Mask, Operand Class, Features */
{ "cdp", 29 /* 0, 2, 3, 4 */, MCK_Coproc, Feature_IsThumb|Feature_HasV6 },
{ "cdp", 58 /* 1, 3, 4, 5 */, MCK_Coproc, Feature_IsARM },
A matcher function very similar (but lot more naive) to
MatchInstructionImpl scans the table. After the mnemonic match, the
features are checked and if the "to be parsed" operand index is
present in the mask, there's a real match. Then, a switch like the one
below dispatch the parsing to the custom method provided in
'ParseMethod':
case MCK_Coproc:
return TryParseCoprocessorOperandName(Operands);
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125030 91177308-0d34-0410-b5e6-96231b3b80d8
(yes, this is different from R_ARM_CALL)
- Adds a new method getARMBranchTargetOpValue() which handles the
necessary distinction between the conditional and unconditional br/bl
needed for ARM/ELF
At least for ARM mode, the needed fixup for conditional versus unconditional
br/bl is identical, but the ARM docs and existing ARM tools expect this
reloc type...
Added a few FIXME's for future naming fixups in ARMInstrInfo.td
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124895 91177308-0d34-0410-b5e6-96231b3b80d8
library.
Installs tblgen (required by Clang).
Translates handling of user settings and platform-dependant options to
its own file, where it can included by another project.
Installs the .cmake files required by projects like Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124816 91177308-0d34-0410-b5e6-96231b3b80d8
The algorithm for identifying which operand is invalid will now always point to
some operand and not the mnemonic sometimes. The change is now that ErrorInfo
is the index of the highest operand that does not match for any of the matching
mnemonics records. And no longer the ~0U value when the mnemonic matches and
not every record with a matching mnemonic has the same mismatching operand
index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124734 91177308-0d34-0410-b5e6-96231b3b80d8
makes type checking for extract_subvector and insert_subvector more
robust and will allow stricter typechecking of more patterns in the
future.
This change handles int and fp as disjoint sets so that it will
enforce integer types to be smaller than the largest integer type and
fp types to be smaller than the largest fp type. There is no attempt
to check type sizes across the int/fp sets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124672 91177308-0d34-0410-b5e6-96231b3b80d8
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
registers that alias Reg, including itself. This is almost the same as the
existing getAliasSet() method, except for the inclusion of Reg.
The name matches the reflexive TRI::regsOverlap(x, y) relation.
It is very common to do stuff to a register and all its aliases:
stuff(Reg)
for (const unsigned *Alias = TRI->getAliasSet(Reg); *Alias; ++Alias)
stuff(*Alias);
That can now be written as the simpler:
for (const unsigned *Alias = TRI->getOverlaps(Reg); *Alias; ++Alias)
stuff(*Alias);
This change requires a bit more constant space for the alias lists because Reg
is included and because the empty alias list cannot be shared any longer.
If the getAliasSet method is eventually removed, this space can be reclaimed by
sharing overlap lists. For instance, %rax and %eax have identical overlap sets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121800 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
Use the same COPY_TO_REGCLASS approach as for the 2-register *_sfp instructions.
This change made a big difference in the code generated for the
CodeGen/Thumb2/cross-rc-coalescing-2.ll test: The coalescer is still doing
a fine job, but some instructions that were previously moved outside the loop
are not moved now. It's using fewer VFP registers now, which is generally
a good thing, so I think the estimates for register pressure changed and that
affected the LICM behavior. Since that isn't obviously wrong, I've just
changed the test file. This completes the work for Radar 8711675.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121730 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
class A<bit a, bits<3> x, bits<3> y> {
bits<3> z;
let z = !if(a, x, y);
}
The variable z will get the value of x when 'a' is 1 and 'y' when a is '0'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121666 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the previous header. I don't think we need to expose to end users
that we use TableGen to produce our version of arm_neon.h, and that header
was also using doubleslash comments which could be a problem when using it
in strict C89 compilations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121390 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
An OpReinterpret entry is handled by translating it to OpCast intrinsics for
all combinations of source and destination types with the same total size.
This will be used to generate all the vreinterpret intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121087 91177308-0d34-0410-b5e6-96231b3b80d8
