| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
Previously LLVM_HAS_GLOBAL_ISEL would directly get the value of
LLVM_BUILD_GLOBAL_ISEL. This could be any integer value and not just ON
and OFF. The problem is that lit.cfg was checking for ON to define that
global-isel was supported, thus if we were setting
LLVM_BUILD_GLOBAL_ISEL with an integer value, say 1, this test would
fail whereas we do build global-isel and want to test it.
llvm-svn: 276307
|
| |
|
|
|
|
|
|
| |
Previously LLVM_BUILD_GLOBAL_ISEL was a boolean variable and although,
this is strictly identical to an option, it did not convey the
information that the user may set it. Options are here for that.
llvm-svn: 276306
|
| |
|
|
|
|
| |
Group arithmetic operations, bitwise operations, and branch operations.
llvm-svn: 276305
|
| |
|
|
|
|
|
| |
Making smaller pieces out of some of these ~1000 line functions should make
it easier to incrementally upgrade them to handle vector types.
llvm-svn: 276304
|
| |
|
|
| |
llvm-svn: 276302
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22538
llvm-svn: 276298
|
| |
|
|
|
|
| |
This commit adds a generic AND opcode to global-isel.
llvm-svn: 276297
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D21646
llvm-svn: 276294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
limits.
Summary:
This change also changes findMatchingInsn and
findMatchingUpdateInsnForward to take DBG_VALUE opcodes into account
when tracking register defs and uses, which could potentially inhibit
these optimizations in the presence of debug information.
Reviewers: mcrosier
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D22582
llvm-svn: 276293
|
| |
|
|
|
|
|
| |
Doesn't make a difference on x86, but avoids memory barriers on
weakly-ordered archs like PowerPC and ARM.
llvm-svn: 276291
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under normal circumstances we prefer the higher performance MOVD to extract the 0'th element of a v8i16 vector instead of PEXTRW.
But as detailed on PR27265, this prevents the SSE41 implementation of PEXTRW from folding the store of the 0'th element. Additionally it prevents us from making use of the fact that the (SSE2) reg-reg version of PEXTRW implicitly zero-extends the i16 element to the i32/i64 destination register.
This patch only preferentially lowers to MOVD if we will not be zero-extending the extracted i16, nor prevent a store from being folded (on SSSE41).
Fix for PR27265.
Differential Revision: https://reviews.llvm.org/D22509
llvm-svn: 276289
|
| |
|
|
| |
llvm-svn: 276287
|
| |
|
|
|
|
| |
As requested on D22509, I've pulled out the v8i16 extraction lowering as the SSE41 and pre-SSE41 implementations are effectively the same.
llvm-svn: 276285
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 276284
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As reported on PR26235, we don't currently make use of the VBROADCASTF128/VBROADCASTI128 instructions (or the AVX512 equivalents) to load+splat a 128-bit vector to both lanes of a 256-bit vector.
This patch enables lowering from subvector insertion/concatenation patterns and auto-upgrades the llvm.x86.avx.vbroadcastf128.pd.256 / llvm.x86.avx.vbroadcastf128.ps.256 intrinsics to match.
We could possibly investigate using VBROADCASTF128/VBROADCASTI128 to load repeated constants as well (similar to how we already do for scalar broadcasts).
Differential Revision: https://reviews.llvm.org/D22460
llvm-svn: 276281
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 276278
|
| |
|
|
|
|
|
|
| |
This provides an elegant pattern to solve the "construct if not in map
already" problem we have many times in LLVM. Without try_emplace we
either have to rely on a sentinel value (nullptr) or do two lookups.
llvm-svn: 276277
|
| |
|
|
|
|
|
| |
Coincidentally this function maps to the C++17 try_emplace. Rename it
for consistentcy with C++17 std::map. NFC.
llvm-svn: 276276
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: tstellarAMD, vpykhtin
Subscribers: arsenm, kzhuravl
Differential Revision: https://reviews.llvm.org/D22620
llvm-svn: 276274
|
| |
|
|
|
|
|
|
| |
The clearance calculation did not take into account registers defined as outputs or clobbers in inline assembly machine instructions because these register defs are implicit.
Differential Revision: http://reviews.llvm.org/D22580
llvm-svn: 276266
|
| |
|
|
|
|
|
| |
StringMap is designed to hold large values. No functionality change
intended.
llvm-svn: 276265
|
| |
|
|
| |
llvm-svn: 276264
|
| |
|
|
| |
llvm-svn: 276257
|
| |
|
|
|
|
|
| |
If we have optimization hints with agree with each other along different
paths, preserve them.
llvm-svn: 276248
|
| |
|
|
|
|
|
| |
We hoisted loads/stores without taking into account which can cause
miscompiles.
llvm-svn: 276240
|
| |
|
|
| |
llvm-svn: 276239
|
| |
|
|
| |
llvm-svn: 276237
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the C API.
Summary: See D19181 for context.
Reviewers: whitequark, Wallbraker, jyknight, echristo, bkramer, void
Subscribers: mehdi_amini
Differential Revision: http://reviews.llvm.org/D21265
llvm-svn: 276236
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a very subtle bug in regmask calculation. Thanks to zan
jyu Wong <zyfwong@gmail.com> for bringing this to notice.
For example if CL is only clobbered than CH should not be marked
clobbered but CX, RCX and ECX should be mark clobbered. Previously for
each modified register all of its aliases are marked clobbered by
markRegClobbred() in RegUsageInfoCollector.cpp but that is wrong because
when CL is clobbered then MRI::isPhysRegModified() will return true for
CL, CX, ECX, RCX which is correct behavior but then for CX, EXC, RCX we
mark CH also clobbered as CH is aliased to CX,ECX,RCX so
markRegClobbred() is not required because isPhysRegModified already take
cares of proper aliasing register. A very simple test case has been
added to verify this change.
Please find relevant bug report here :
http://llvm.org/PR28567
Patch by Vivek Pandya <vivekvpandya@gmail.com>
Differential Revision: https://reviews.llvm.org/D22400
llvm-svn: 276235
|
| |
|
|
| |
llvm-svn: 276224
|
| |
|
|
|
|
|
| |
Test coverage is provided by modifying the function in the FP-math
testcase that we are allowed to vectorize.
llvm-svn: 276223
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
classifyLEAReg() deals with switching operands from 32bit to 64bit in
order to use a LEA64_32 instruction (for three address code goodness).
It currently performs a liveness analysis to determine the kill/undef
flag for the newly added operand. This should not be necessary:
- If the previous operand had a kill flag, then the 32bit part of the
register gets killed, this will kill the super register as well.
- If the previous operand had an undef flag then we didn't care what
value we read, just use the same flag on the new operand.
(No matter what an operand with an undef flag won't affect liveness)
This makes the code independent of the presence of kill flags because it
avoids a call to MachineBasicBlock::computeRegisterLiveness().
Differential Revision: http://reviews.llvm.org/D22283
llvm-svn: 276222
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The benefits of this change include:
1. Remove DeMorgan-matching code that was added specifically to work-around
the missing transform in http://reviews.llvm.org/rL248634.
2. Makes the DeMorgan transform work for vectors too.
3. Fix PR28476: https://llvm.org/bugs/show_bug.cgi?id=28476
Extending this transform to other casts and other associative operators may
be useful too. See https://reviews.llvm.org/D22421 for a prerequisite for
doing that though.
Differential Revision: https://reviews.llvm.org/D22271
llvm-svn: 276221
|
| |
|
|
|
|
|
|
| |
This includes FPCompute and Aliasing.
Testcase is based on no_fpmath.ll.
llvm-svn: 276211
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22602
llvm-svn: 276209
|
| |
|
|
| |
llvm-svn: 276205
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 276202
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Also, refactor our constexpr handling to be less insane).
This patch lets us track field offsets in the CFL Graph, which is the
first step to making CFLAA field/offset sensitive. Woohoo! Note that
this patch shouldn't visibly change our behavior (since we make no use
of the offsets we're now tracking), so we can't quite add tests for this
yet.
Patch by Jia Chen.
Differential Revision: https://reviews.llvm.org/D22598
llvm-svn: 276201
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22544
llvm-svn: 276199
|
| |
|
|
|
|
| |
Fix the test case that should not depend on dir iteration order.
llvm-svn: 276197
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: tra
Subscribers: jholewinski, arsenm, asbirlea
Differential Revision: https://reviews.llvm.org/D22592
llvm-svn: 276196
|
| |
|
|
| |
llvm-svn: 276194
|
| |
|
|
|
|
| |
-run-pass. NFCI.
llvm-svn: 276193
|
| |
|
|
|
|
|
|
| |
The earlier change added hotness attribute to missed-optimization
remarks. This follows up with the analysis remarks (the ones explaining
the reason for the missed optimization).
llvm-svn: 276192
|
| |
|
|
|
|
|
|
| |
This helps because LoopAccessReport is passed around as a const
reference and we derive the basic block passed as the Value parameter
from the instruction in LoopAccessReport.
llvm-svn: 276191
|
| |
|
|
| |
llvm-svn: 276190
|
| |
|
|
|
|
|
|
| |
After r276153 the pass applies to both kernels and regular functions.
Differential Revision: https://reviews.llvm.org/D22583
llvm-svn: 276189
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D22560
llvm-svn: 276185
|
| |
|
|
|
|
|
| |
This adds an (incomplete, inefficient) framework for deciding what to do with
some operation on a given type.
llvm-svn: 276184
|