| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
The instructions that use this class don't have another source register. So I think this was just marking one of the address operands as ReadAfterLd?
llvm-svn: 334994
|
| |
|
|
|
|
|
|
|
|
|
| |
MergeBlockIntoPredecessor"
This reverts commit f976cf4cca0794267f28b54e468007fd476d37d9.
I am reverting this because it causes break in a few bots and its going
to take me sometime to look at this.
llvm-svn: 334993
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Simplify blockaddress usage before giving up in MergeBlockIntoPredecessor
This is a missing small optimization in MergeBlockIntoPredecessor.
This helps with one simplifycfg test which expects this case to be handled.
Reviewers: davide, spatel, brzycki, asbirlea
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48284
llvm-svn: 334992
|
| |
|
|
| |
llvm-svn: 334990
|
| |
|
|
|
|
|
| |
the individual stub creation to increase readability a bit in the
non-object file format specific function.
llvm-svn: 334989
|
| |
|
|
|
|
|
|
| |
exclusive conditions.
else if would have worked just as well, but this keeps the original readability a bit more clear.
llvm-svn: 334988
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
One for register based, much like the existing definitions,
and one for stack based (suffix _S).
This allows us to use registers in most of LLVM (which works better),
and stack based in MC (which results in a simpler and more readable
assembler / disassembler).
Tried to keep this change as small as possible while passing tests,
follow-up commit will:
- Add reg->stack conversion in MI.
- Fix asm/disasm in MC to be stack based.
- Fix emitter to be stack based.
tests passing:
llvm-lit -v `find test -name WebAssembly`
test/CodeGen/WebAssembly
test/MC/WebAssembly
test/MC/Disassembler/WebAssembly
test/DebugInfo/WebAssembly
test/CodeGen/MIR/WebAssembly
test/tools/llvm-objdump/WebAssembly
Reviewers: dschuff, sbc100, jgravelle-google, sunfish
Subscribers: aheejin, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D48183
llvm-svn: 334985
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Refactoring for all constant cases which require AllowNewConst and some staging for future fmf usage.
Reviewers: spatel, hfinkel, wristow
Reviewed By: spatel
Subscribers: nhaehnle
Differential Revision: https://reviews.llvm.org/D48289
llvm-svn: 334984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch uses the DiagnosticPredicate for SVE predicate patterns
to improve their diagnostics, now giving a 'invalid operand' diagnostic
if the type is not an immediate or one of the expected pattern
labels.
Reviewers: samparker, SjoerdMeijer, javed.absar, fhahn
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D48220
llvm-svn: 334983
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The variants added by this patch are:
- SQINC signed increment, e.g. sqinc x0, w0, all, mul #4
- SQDEC signed decrement, e.g. sqdec x0, w0, all, mul #4
- UQINC unsigned increment, e.g. uqinc w0, all, mul #4
- UQDEC unsigned decrement, e.g. uqdec w0, all, mul #4
This patch includes asmparser changes to parse a GPR64 as a GPR32 in
order to satisfy the constraint check:
x0 == GPR64(w0)
in:
sqinc x0, w0, all, mul #4
^___^ (must match)
Reviewers: rengolin, fhahn, SjoerdMeijer, samparker, javed.absar
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D47716
llvm-svn: 334980
|
| |
|
|
|
|
|
|
| |
Tested: llvm-lit -v `find test -name WebAssembly`
(This is a commit access "test commit" :)
llvm-svn: 334979
|
| |
|
|
|
|
|
|
| |
the emitter source.
Rather than having an exclusion list in tablegen sources, add a flag to the X86 instruction records that can be used to suppress checking for convertibility.
llvm-svn: 334971
|
| |
|
|
| |
llvm-svn: 334970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a VPInstructionToVPRecipe transformation, which
allows us to generate code for a VPInstruction based VPlan re-using the
existing infrastructure.
Reviewers: dcaballe, hsaito, mssimpso, hfinkel, rengolin, mkuper, javed.absar, sguggill
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D46827
llvm-svn: 334969
|
| |
|
|
|
|
|
|
|
| |
CompileOnDemandLayer2 is a replacement for CompileOnDemandLayer built on the ORC
Core APIs. Functions in added modules are extracted and compiled lazily.
CompileOnDemandLayer2 supports multithreaded JIT'd code, and compilation on
multiple threads.
llvm-svn: 334967
|
| |
|
|
|
|
|
|
|
|
|
|
| |
materializing weak symbols as strong.
This removes some elaborate flag tweaking and plays nicer with RuntimeDyld,
which relies of weak/common flags to determine whether it should emit a given
weak definition. (Switching to strong up-front makes it appear as if there is
already an overriding definition, which would require an extra back-channel to
override).
llvm-svn: 334966
|
| |
|
|
| |
llvm-svn: 334963
|
| |
|
|
| |
llvm-svn: 334959
|
| |
|
|
|
|
|
|
|
|
| |
Ensure we keep track of the input vectors in all cases instead of just for SK_Select.
Ideally we'd reuse the shuffle mask pattern matching in TargetTransformInfo::getInstructionThroughput here to easily add support for all TargetTransformInfo::ShuffleKind without mass code duplication, I've added a TODO for now but D48236 should help us here.
Differential Revision: https://reviews.llvm.org/D48023
llvm-svn: 334958
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: dcaballe, hsaito, mkuper, hfinkel
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D48081
llvm-svn: 334951
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The variants added by this patch are:
- SQINC (signed increment)
- UQINC (unsigned increment)
- SQDEC (signed decrement)
- UQDEC (unsigned decrement)
For example:
uqincw x0, all, mul #4
Reviewers: rengolin, fhahn, SjoerdMeijer, samparker, javed.absar
Differential Revision: https://reviews.llvm.org/D47715
llvm-svn: 334948
|
| |
|
|
|
|
|
|
| |
Jaguar only supports up to AVX1
Differential Revision: https://reviews.llvm.org/D48274
llvm-svn: 334947
|
| |
|
|
| |
llvm-svn: 334943
|
| |
|
|
| |
llvm-svn: 334934
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: dcaballe, mkuper, hfinkel, hsaito, mssimpso
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D48080
llvm-svn: 334933
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds instructions for comparing elements from two vectors, e.g.
cmpgt p0.s, p0/z, z0.s, z1.s
and also adds support for comparing to a 64-bit wide element vector, e.g.
cmpgt p0.s, p0/z, z0.s, z1.d
The patch also contains aliases for certain comparisons, e.g.:
cmple p0.s, p0/z, z0.s, z1.s => cmpge p0.s, p0/z, z1.s, z0.s
cmplo p0.s, p0/z, z0.s, z1.s => cmphi p0.s, p0/z, z1.s, z0.s
cmpls p0.s, p0/z, z0.s, z1.s => cmphs p0.s, p0/z, z1.s, z0.s
cmplt p0.s, p0/z, z0.s, z1.s => cmpgt p0.s, p0/z, z1.s, z0.s
llvm-svn: 334931
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Noop certainly does not use resources.
Reviewers: RKSimon, craig.topper, andreadb
Subscribers: gbedwell, llvm-commits, gchatelet
Differential Revision: https://reviews.llvm.org/D48028
llvm-svn: 334927
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the heap. NFCI
Previously we heap allocated the X86InstrFMA3Group objects which were created by passing them small register/memory opcode arrays that existed as individual static tables.
Rather than a bunch of small static arrays we now have one large static table of X86InstrFMA3Group objects. Rather than storing a pointer to the opcode arrays in the X86InstrFMA3Group object, we now store have a register and memory array as part of the object. If a group doesn't have memory or register opcodes, the array entries will be 0.
This greatly simplifies the destruction of the X86InstrFMA3Info object. We no longer need to delete the X86InstrFMA3Group objects as we destruct the DenseMap. And we don't need to keep track of which ones we already deleted.
This reduces the llc binary size on my local machine by ~50k. I can only assume that's really due to the fact that we had something like 512 small static arrays that we passed to the init functions either one at a time or in pairs. So there were between 256 and 512 distinct calls to the init functions in the initOnceImpl method.
llvm-svn: 334925
|
| |
|
|
|
|
|
|
|
|
| |
encodings to match gas and our EVEX instructions.
We already have these aliases for EVEX enocded instructions, but not for the GPR, MMX, SSE, and VEX versions.
Also remove the vpextrw.s EVEX alias. That's not something gas implements.
llvm-svn: 334922
|
| |
|
|
|
|
|
|
|
|
| |
with reversed operands to InstAliases.
The .s assembly strings allow the reversed forms to be targeted from assembly which matches gas behavior. But when printing the instructions we should print them without the .s to match other tooling like objdump. By using InstAliases we can use the normal string in the instruction and just hide it from the assembly parser.
Ideally we'd add the .s versions to the legacy SSE and VEX versions as well for full compatibility with gas. Not sure how we got to state where only EVEX was supported.
llvm-svn: 334920
|
| |
|
|
| |
llvm-svn: 334918
|
| |
|
|
|
|
|
|
| |
changes.
This guards against redundant notifications.
llvm-svn: 334916
|
| |
|
|
|
|
|
|
| |
instead of proxying through X86InstrFMA3Info.
These increases the size of the static tables, but is closer to what we would get if used the autogenerated table directly. This reduces the remaining large deltas between what's in the manual table and what's in the autogenerated table.
llvm-svn: 334915
|
| |
|
|
| |
llvm-svn: 334911
|
| |
|
|
| |
llvm-svn: 334910
|
| |
|
|
|
|
|
|
|
|
|
| |
symbols in debug mode.
The MaterializationResponsibility class hijacks the Materializing flag to track
symbols that have not yet been resolved in order to guard against redundant
resolution. Since this is an API contract check and only enforced in debug mode
there is no reason to maintain the flag state in release mode.
llvm-svn: 334909
|
| |
|
|
|
|
|
|
|
|
| |
simplify the hasSingleUseFromRoot handling.
Some of the calls to hasSingleUseFromRoot were passing the load itself. If the load's chain result has a user this would count against that. By getting the true parent of the match and ensuring any intermediate between the match and the load have a single use we can avoid this case. isLegalToFold will take care of checking users of the load's data output.
This fixed at least fma-scalar-memfold.ll to succed without the peephole pass.
llvm-svn: 334908
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for instructions performing bitwise operations
on predicate vectors, including AND, BIC, EOR, NAND, NOR, ORN, ORR, and
their status flag setting variants ANDS, BICS, EORS, NANDS, ORNS, ORRS.
This patch also adds several aliases:
orr p0.b, p1/z, p1.b, p1.b => mov p0.b, p1.b
orrs p0.b, p1/z, p1.b, p1.b => movs p0.b, p1.b
and p0.b, p1/z, p2.b, p2.b => mov p0.b, p1/z, p2.b
ands p0.b, p1/z, p2.b, p2.b => movs p0.b, p1/z, p2.b
eor p0.b, p1/z, p2.b, p1.b => not p0.b, p1/z, p2.b
eors p0.b, p1/z, p2.b, p1.b => nots p0.b, p1/z, p2.b
llvm-svn: 334906
|
| |
|
|
|
|
|
|
| |
Support for SVE's predicated select instructions to select elements
from either vector, both in a data-vector and a predicate-vector
variant.
llvm-svn: 334905
|
| |
|
|
|
|
|
|
|
|
| |
We don't want to prevent inlining because of target-cpu and -features
attributes that were added to newer versions of LLVM/Clang: There are
no incompatible functions in PTX, ptxas will throw errors in such cases.
Differential Revision: https://reviews.llvm.org/D47691
llvm-svn: 334904
|
| |
|
|
| |
llvm-svn: 334899
|
| |
|
|
|
|
|
|
| |
tables.
Including more additions for NotMemoryFoldable to remove some entries from the autogenerated table.
llvm-svn: 334898
|
| |
|
|
|
|
|
|
| |
parser.
These all have a short form encoding that the assembler already prefers. Though that preference seems to only be based on order in the .td fie. Hiding the long form saves space in the table and prevents us from breaking the implicit order based priority.
llvm-svn: 334897
|
| |
|
|
|
|
|
|
|
|
| |
instructions.
VMOVPQIto64Zmr is not a 64-bit mode only instruction. But I don't know how to test this because VMOVPQIto64mr should always have priority over it in 32-bit mode since its only advantage is XMM16-XMM31 which aren't usable in 32-bit mode.
VMOVPQIto64Zrr is a 64-bit mode only instruction, but we don't need to explicitly mark it as such because it uses a GR64 register which won't parse in 32-bit mode.
llvm-svn: 334896
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We only modify CFG in a couple of places, and we can preserve DT there
with a little effort.
Reviewers: davide, vsk
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D48059
llvm-svn: 334895
|
| |
|
|
| |
llvm-svn: 334890
|
| |
|
|
|
|
|
|
|
| |
This is the common case in the BE when we serialize condition and then
rematerialize it. Use either original or inverted condition.
Differential Revision: https://reviews.llvm.org/D48246
llvm-svn: 334882
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relanding after fixing expensive check from modifying tables.
To avoid redundant work, during DAG legalization we keep tables
mapping pre-legalized SDValues to post-legalized SDValues and a
SDValue-to-SDValue map to enable fast node replacements. However, as
the keys are nodes which may be reused it is possible that an entry in
a table refers to a now deleted node N (that should have been renamed
by the value replacement map) while a new node N' exists. If N' is
then replaced that entry would be wrong. Previously we avoided this by
when potentially violating this property, walking every table and
updating all node pointers. This is very expensive but hopefully rare
occurance.
This patch assigns each instance of a SDValue used in legalization a
unique id and uses these ids in the legalization tables. This avoids
any such aliasing issue, avoiding the full table search and allowing
more aggressive incremental table pruning.
In some cases this is a 1000x speedup to compilation.
Reviewers: jyknight, echristo, bogner, tra
Reviewed By: bogner
Subscribers: dberris, grandinj, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D47959
llvm-svn: 334880
|
| |
|
|
|
|
| |
This reverts D48237.
llvm-svn: 334878
|
| |
|
|
|
|
|
|
| |
breaks MSVC builds.
This reverts D48238.
llvm-svn: 334877
|