There were several cases in X86 where we were unable to fully factor a ScopeMatcher but created nested ScopeMatchers for some portions of it. Then we created a SwitchType that split it up and further factored it so that we ended up with something like this:
SwitchType
Scope
Scope
Sequence of matchers
Some other sequence of matchers
EndScope
Another sequence of matchers
EndScope
...Next type
This change turns it into this:
SwitchType
Scope
Sequence of matchers
Some other sequence of matchers
Another sequence of matchers
EndScope
...Next type
Several other in-tree targets had similar nested scopes like this. Overall this doesn't save many bytes, but makes the isel output a little more regular.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287624 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
For Sparc the namespace (SP) is different from the target name (Sparc),
which causes the name of the array in this declaration to differ from
the name used in the definition.
Patch by Daniel Cederman.
Reviewers: jyknight
Subscribers: llvm-commits, jyknight
Differential Revision: https://reviews.llvm.org/D23650
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287528 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we were factoring when the ScopeMatcher was initially created, but it might get more Matchers added to it later. Delay factoring until we have fully created/populated the ScopeMatchers.
This reduces X86 isel tables by 154 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287520 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
* ARM is omitted from this patch because this check appears to expose bugs in this target.
* Mips is omitted from this patch because this check either detects bugs or deliberate
emission of instructions that don't satisfy their predicates. One deliberate
use is the SYNC instruction where the version with an operand is correctly
defined as requiring MIPS32 while the version without an operand is defined
as an alias of 'SYNC 0' and requires MIPS2.
* X86 is omitted from this patch because it doesn't use the tablegen-erated
MCCodeEmitter infrastructure.
Patches for ARM and Mips will follow.
Depends on D25617
Reviewers: tstellarAMD, jmolloy
Subscribers: wdng, jmolloy, aemerson, rengolin, arsenm, jyknight, nemanjai, nhaehnle, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D25618
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287439 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change is preparation for a change that will allow targets to verify that the instructions
they emit meet the predicates they specify. This is useful to ensure that C++
legalization/lowering/instruction-selection doesn't incorrectly select code for a different
subtarget than intended. Such cases are not caught by the integrated assembler when emitting
instructions directly to an object file.
Reviewers: qcolombet
Subscribers: qcolombet, beanz, mgorny, llvm-commits, modocache
Differential Revision: https://reviews.llvm.org/D25614
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286945 91177308-0d34-0410-b5e6-96231b3b80d8
Teach X86InstrInfo::analyzeCompare() not to crash on CMP and SUB instructions
that take a global address operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286420 91177308-0d34-0410-b5e6-96231b3b80d8
Suspected to be the cause of a sanitizer-windows bot failure:
Assertion failed: isImm() && "Wrong MachineOperand accessor", file C:\b\slave\sanitizer-windows\llvm\include\llvm/CodeGen/MachineOperand.h, line 420
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286385 91177308-0d34-0410-b5e6-96231b3b80d8
A relocatable immediate is either an immediate operand or an operand that
can be relocated by the linker to an immediate, such as a regular symbol
in non-PIC code.
Start using relocImm for 32-bit and 64-bit MOV instructions, and for operands
of type "imm32_su". Remove a number of now-redundant patterns.
Differential Revision: https://reviews.llvm.org/D25812
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286384 91177308-0d34-0410-b5e6-96231b3b80d8
2 new intrinsics covering AVX-512 compress/expand functionality.
This implementation includes syntax, DAG builder, operation lowering and tests.
Does not include: handling of illegal data types, codegen prepare pass and the cost model.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285876 91177308-0d34-0410-b5e6-96231b3b80d8
As it stands, the OperandMatchResultTy is only included in the generated
header if there is custom operand parsing. However, almost all backends
make use of MatchOperand_Success and friends from OperandMatchResultTy for
e.g. parseRegister. This is a pain when starting an AsmParser for a new
backend that doesn't yet have custom operand parsing. Move the enum to
MCTargetAsmParser.h.
This patch is a prerequisite for D23563
Differential Revision: https://reviews.llvm.org/D23496
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285705 91177308-0d34-0410-b5e6-96231b3b80d8
The CodeGenSchedModels::checkCompleteness routine in TableGen/
CodeGenSchedule.cpp is supposed to verify for each processor
model that is marked as "complete" that it actually defines a
scheduling class for each instruction.
However, this did not work correctly due to an incorrect
check whether a scheduling class has an itinerary.
Reviewer: atrick
Differential revision: https://reviews.llvm.org/D26156
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285622 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
SetVector already used DenseSet, but SmallSetVector used std::set. This
leads to surprising performance differences. Moreover, it means that
the set of key types accepted by SetVector and SmallSetVector are
quite different!
In order to make this change, we had to convert some callsites that used
SmallSetVector<std::string, N> to use SmallSetVector<CachedHashString, N>
instead.
Reviewers: timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25648
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284887 91177308-0d34-0410-b5e6-96231b3b80d8
-debug-only=subtarget-emitter prints a lot of machine model diagnostics.
This prunes the output so that the "No machine model for XXX on processor YYY"
only appears when there is definitely no machine model for that opcode.
Previously it was printing that error even if the opcode was covered by
a more general scheduling class.
<rdar://problem/15919845> [TableGen][CodeGenSchedule] Debug output does not help spotting the missing scheduling classes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284452 91177308-0d34-0410-b5e6-96231b3b80d8
The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when calling:
va_start(ValueArgs, Desc);
with Desc being a StringRef.
Differential Revision: https://reviews.llvm.org/D25342
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283671 91177308-0d34-0410-b5e6-96231b3b80d8
hwloop regression tests. These tests pass locally; will be investigating
where these differences come from.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281306 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This allows specifying instructions that are available only in specific assembler variant. If AsmVariantName is specified then instruction will be presented only in MatchTable for this variant. If not specified then assembler variants will be determined based on AsmString.
Also this allows splitting assembler match tables in same way as it is done in dissasembler.
Reviewers: ab, tstellarAMD, craig.topper, vpykhtin
Subscribers: wdng
Differential Revision: https://reviews.llvm.org/D24249
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280952 91177308-0d34-0410-b5e6-96231b3b80d8
This mapping is between pointers, which DenseMap is particularly good
at. Most targets aren't really affected, but if there's a lot of
subregister composition this can shave off a good chunk of time from
generating registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279875 91177308-0d34-0410-b5e6-96231b3b80d8
This tries to keep all the ModRM memory and register forms in their own regions of the encodings. Hoping to make it simple on some of the switch statements that operate on these encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279422 91177308-0d34-0410-b5e6-96231b3b80d8
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278469 91177308-0d34-0410-b5e6-96231b3b80d8
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278433 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is one possible solution to the problem of ignoring constraints that Simon
raised in D21473 but it's a bit of a hack.
The integrated assembler currently ignores violations of the tied register
constraints when the operands involved in a tie are both present in the AsmText.
For example, 'dati $rs, $rt, $imm' with the '$rs = $rt' will silently replace
$rt with $rs. So 'dati $2, $3, 1' is processed as if the user provided
'dati $2, $2, 1' without any diagnostic being emitted.
This is difficult to solve properly because there are multiple parts of the
matcher that are silently forcing these constraints to be met. Tied operands are
rendered to instructions by cloning previously rendered operands but this is
unnecessary because the matcher was already instructed to render the operand it
would have cloned. This is also unnecessary because earlier code has already
replaced the MCParsedOperand with the one it was tied to (so the parsed input
is matched as if it were 'dati <RegIdx 2>, <RegIdx 2>, <Imm 1>'). As a result,
it looks like fixing this properly amounts to a rewrite of the tied operand
handling which affects all targets.
This patch however, merely inserts a checking hook just before the
substitution of MCParsedOperands and the Mips target overrides it. It's not
possible to accurately check the registers are the same this early (because
numeric registers haven't been bound to a register class yet) so it cheats a
bit and checks that the tokens that produced the operand are lexically
identical. This works because tied registers need to have the same register
class but it does have a flaw. It will reject 'dati $4, $a0, 1' for violating
the constraint even though $a0 ends up as the same register as $4.
Reviewers: sdardis
Subscribers: dsanders, llvm-commits, sdardis
Differential Revision: https://reviews.llvm.org/D21994
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276867 91177308-0d34-0410-b5e6-96231b3b80d8
Avoids a call to strlen on both strings which always reads the entire
string. strcmp can use early exit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276737 91177308-0d34-0410-b5e6-96231b3b80d8
They were all auto-incremented from 0 anyway, and I'm getting really annoying
conflicts and runtime failures when different people add more for GlobalISel
(and even when I'm refactoring my own patches).
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276204 91177308-0d34-0410-b5e6-96231b3b80d8
This is for a situation where the encoding for a register may be
different depending on the specific operand. For some instructions,
we want to apply additional restrictions beyond the encoding's
constraints.
In AMDGPU some operands are VSrc_32, using the VS_32 pseudo register
class which accept VGPRs, SGPRs, or immediates in the encoding.
Some specific instructions with the same encoding operand do not want
to allow immediates or SGPRs, but the encoding format is different
in this case than a regular VGPR_32 operand.
This allows specifying the encoding should be treated the same
without introducing yet another dummy register class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275929 91177308-0d34-0410-b5e6-96231b3b80d8
This splits out the intrinsic table such that generic intrinsics come
first and target specific intrinsics are grouped by target. From here
we can find out which target an intrinsic is for or differentiate
between generic and target intrinsics.
The motivation here is to make it easier to move target specific
intrinsic handling out of generic code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275575 91177308-0d34-0410-b5e6-96231b3b80d8
