| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
immediate.
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
llvm-svn: 286384
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 285876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 285705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 285622
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sanitizer-windows bot turned red with:
FAILED: utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/IntrinsicEmitter.cpp.obj
C:\PROGRA~2\MICROS~1.0\VC\bin\AMD64_~2\cl.exe ... -c
C:\...\llvm\utils\TableGen\IntrinsicEmitter.cpp
c:\...\llvm\utils\tablegen\intrinsicemitter.cpp(254) :
fatal error C1001: An internal error has occurred in the compiler.
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/114/steps/build%20clang%20lld/logs/stdio
llvm-svn: 285089
|
|
|
|
|
|
|
| |
Things seem to build fine locally without this, so let's
see what the bots think.
llvm-svn: 285087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 284887
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
llvm-svn: 284452
|
|
|
|
| |
llvm-svn: 283814
|
|
|
|
| |
llvm-svn: 283792
|
|
|
|
| |
llvm-svn: 283691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template
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
llvm-svn: 283671
|
|
|
|
| |
llvm-svn: 283366
|
|
|
|
| |
llvm-svn: 283273
|
|
|
|
| |
llvm-svn: 283268
|
|
|
|
| |
llvm-svn: 283043
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenSubRegIndex. NFC"
It turns out we iterate over this map a fair amount and the order
matters for clang to be deterministic. See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160919/391315.html
This reverts r279875.
llvm-svn: 282040
|
|
|
|
|
|
| |
to copy the new isAdd field in the tablegen data structure.
llvm-svn: 281447
|
|
|
|
|
|
|
| |
hwloop regression tests. These tests pass locally; will be investigating
where these differences come from.
llvm-svn: 281306
|
|
|
|
|
|
|
|
|
|
|
| |
descriptions now tag add instructions, and the Hexagon backend is using this to
identify loop induction statements.
Patch by Sam Parker and Sjoerd Meijer.
Differential Revision: https://reviews.llvm.org/D23601
llvm-svn: 281304
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 280952
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 279875
|
|
|
|
|
|
| |
one bit in TSFlags and simplifies MRMSrcMem/MRMSrcReg format handling.
llvm-svn: 279424
|
|
|
|
|
|
| |
one bit in TSFlags and simplifies MRMSrcMem/MRMSrcReg format handling.
llvm-svn: 279423
|
|
|
|
|
|
|
|
| |
new encodings in future commits and this will reduce the size of those commits. NFC
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.
llvm-svn: 279422
|
|
|
|
|
|
| |
both operate on the same variable. NFC
llvm-svn: 279421
|
|
|
|
|
|
| |
easier to detect when one is missing. NFC
llvm-svn: 279420
|
|
|
|
|
|
| |
Follow up to r278902. I had missed "fall through", with a space.
llvm-svn: 278970
|
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 278475
|
|
|
|
|
|
|
|
|
| |
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
llvm-svn: 278469
|
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 278443
|
|
|
|
|
|
|
|
|
| |
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
llvm-svn: 278433
|
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 278417
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 276867
|
|
|
|
|
|
|
| |
Avoids a call to strlen on both strings which always reads the entire
string. strcmp can use early exit.
llvm-svn: 276737
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 276204
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 275929
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 275575
|
|
|
|
| |
llvm-svn: 275450
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In this patch we implement the following parts of XRay:
- Supporting a function attribute named 'function-instrument' which currently only supports 'xray-always'. We should be able to use this attribute for other instrumentation approaches.
- Supporting a function attribute named 'xray-instruction-threshold' used to determine whether a function is instrumented with a minimum number of instructions (IR instruction counts).
- X86-specific nop sleds as described in the white paper.
- A machine function pass that adds the different instrumentation marker instructions at a very late stage.
- A way of identifying which return opcode is considered "normal" for each architecture.
There are some caveats here:
1) We don't handle PATCHABLE_RET in platforms other than x86_64 yet -- this means if IR used PATCHABLE_RET directly instead of a normal ret, instruction lowering for that platform might do the wrong thing. We think this should be handled at instruction selection time to by default be unpacked for platforms where XRay is not availble yet.
2) The generated section for X86 is different from what is described from the white paper for the sole reason that LLVM allows us to do this neatly. We're taking the opportunity to deviate from the white paper from this perspective to allow us to get richer information from the runtime library.
Reviewers: sanjoy, eugenis, kcc, pcc, echristo, rnk
Subscribers: niravd, majnemer, atrick, rnk, emaste, bmakam, mcrosier, mehdi_amini, llvm-commits
Differential Revision: http://reviews.llvm.org/D19904
llvm-svn: 275367
|
|
|
|
|
|
|
|
|
|
| |
attribute
This will be used by the upcoming llvm.noalias intrinsic.
Differential Revision: http://reviews.llvm.org/D22201
llvm-svn: 275034
|
|
|
|
|
|
|
|
| |
Ran clang-format to remove the namespace indentation, and stopped
repeating names in doc comments since I was updating every line
anyway.
llvm-svn: 274919
|
|
|
|
| |
llvm-svn: 274584
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way the named arguments for various system instructions are handled at the
moment has a few problems:
- Large-scale duplication between AArch64BaseInfo.h and AArch64BaseInfo.cpp
- That weird Mapping class that I have no idea what I was on when I thought
it was a good idea.
- Searches are performed linearly through the entire list.
- We print absolutely all registers in upper-case, even though some are
canonically mixed case (SPSel for example).
- The ARM ARM specifies sysregs in terms of 5 fields, but those are relegated
to comments in our implementation, with a slightly opaque hex value
indicating the canonical encoding LLVM will use.
This adds a new TableGen backend to produce efficiently searchable tables, and
switches AArch64 over to using that infrastructure.
llvm-svn: 274576
|
|
|
|
|
|
|
| |
It's being immediately converted to a "string", but being able to tell what
type the field was originally can be useful in backends.
llvm-svn: 274575
|
|
|
|
| |
llvm-svn: 274515
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This complements the earlier addition of IntrWriteMem and IntrWriteArgMem
LLVM intrinsic properties, see D18291.
Also start using the attribute for memset, memcpy, and memmove intrinsics,
and remove their special-casing in BasicAliasAnalysis.
Reviewers: reames, joker.eph
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D18714
llvm-svn: 274485
|
|
|
|
|
|
|
|
| |
This reverts commit r273565.
This was an over-eager revert.
llvm-svn: 273658
|
|
|
|
|
|
|
|
|
| |
The previous code would always do 1 or 2 prefix compares;
explicitly only do one.
This speeds up debug -gen-asm-matcher by ~10% (e.g. X86: 40s -> 35s).
llvm-svn: 273583
|
|
|
|
|
|
|
|
| |
This reverts commit r273551.
Patch contained a wrong check for isUnsupported.
llvm-svn: 273565
|