number of threads. In that case make the number of threads
equal to the number of jobs and launch one jobs on each
thread. This makes things work like make -j.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127045 91177308-0d34-0410-b5e6-96231b3b80d8
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
