| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
This patch implements dynamic stack (re-)alignment for 16-bit Thumb. When
targeting processors, which support only the 16-bit Thumb instruction set
the compiler ignores the alignment attributes of automatic variables and may
silently generate incorrect code.
Differential revision: https://reviews.llvm.org/D38143
llvm-svn: 316289
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pass scans the function to find instruction chains that define
registers in the same domain (closures).
It then calculates the cost of converting the closure to another domain.
If found profitable, the instructions are converted to instructions in
the other domain and the register classes are changed accordingly.
This commit adds the pass infrastructure and a simple conversion from
the GPR domain to the Mask domain.
Differential Revision:
https://reviews.llvm.org/D37251
Change-Id: Ic2cf1d76598110401168326d411128ae2580a604
llvm-svn: 316288
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: sdardis
Subscribers: jaydeep, bhushan, llvm-commits
Differential Revision: https://reviews.llvm.org/D38314
llvm-svn: 316287
|
| |
|
|
|
|
|
|
| |
corresponding VEX.W==1 instruction and we shouldn't treat them as if VEX.W is ignored.
Fixes PR11304.
llvm-svn: 316285
|
| |
|
|
|
|
| |
This should be NFC. Will be used in future patches to fix disassembler bugs.
llvm-svn: 316284
|
| |
|
|
| |
llvm-svn: 316283
|
| |
|
|
|
|
|
|
| |
use a SIB byte.
Fixes PR34998.
llvm-svn: 316282
|
| |
|
|
| |
llvm-svn: 316277
|
| |
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules-2/builds/12899
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/7951
llvm-svn: 316276
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39135
llvm-svn: 316274
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the SIB index register as an XMM/YMM/ZMM register.
This introduces a new operand type to encode the whether the index register should be XMM/YMM/ZMM. And new code to fixup the results created by readSIB.
This has the nice effect of removing a bunch of code that hard coded the name of every GATHER and SCATTER instruction to map the index type.
This fixes PR32807.
llvm-svn: 316273
|
| |
|
|
| |
llvm-svn: 316271
|
| |
|
|
|
|
|
|
|
|
| |
Summary: The two 32-bit words were swapped.
Subscribers: nemanjai, kbarton
Differential Revision: https://reviews.llvm.org/D38705
llvm-svn: 316270
|
| |
|
|
|
|
|
|
| |
computeNumSignBitsVectorConstant.
We can just use getNumSignBits instead of inverting negative numbers.
llvm-svn: 316266
|
| |
|
|
|
|
| |
Neither of these cases really require a temporary APInt outside the loop. For the ConstantDataSequential case the APInt will never be larger than 64-bits so its fine to just call getElementAsAPInt. For ConstantVector we can get the APInt by reference and only make a copy where the inversion is needed.
llvm-svn: 316265
|
| |
|
|
| |
llvm-svn: 316262
|
| |
|
|
|
|
|
|
|
|
|
| |
The way that splitInnerLoopHeader splits blocks requires that
the induction PHI will be the first PHI in the inner loop
header. This makes sure that is actually the case when there
are both IV and reduction phis.
Differential Revision: https://reviews.llvm.org/D38682
llvm-svn: 316261
|
| |
|
|
| |
llvm-svn: 316258
|
| |
|
|
| |
llvm-svn: 316257
|
| |
|
|
|
|
|
|
| |
computeKnownBits and ComputeNumSignBits.
We don't need to do any additional recursion, we just need to analyze the APInt stored in the node. This matches what the ValueTracking versions do for IR.
llvm-svn: 316256
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TargetLowering::SimplifyDemandedBits.
Summary:
We shouldn't recurse any further but it doesn't mean we shouldn't be able to give the known bits for a constant. The caller would probably like that we always return the right answer for a constant RHS. This matches what InstCombine does in this case.
I don't have a test case because this showed up while trying to revive D31724.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: arsenm, llvm-commits
Differential Revision: https://reviews.llvm.org/D38967
llvm-svn: 316255
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test.
Patch by Riyaz V Puthiyapurayil
Reviewers: craig.topper, schweitz
Reviewed By: craig.topper, schweitz
Subscribers: RKSimon, llvm-commits
Differential Revision: https://reviews.llvm.org/D38668
llvm-svn: 316254
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 316253
|
| |
|
|
| |
llvm-svn: 316243
|
| |
|
|
| |
llvm-svn: 316242
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 316241
|
| |
|
|
|
|
|
|
|
| |
At this point we don't output any debug sections or thier
relocations.
Differential Revision: https://reviews.llvm.org/D39076
llvm-svn: 316240
|
| |
|
|
|
|
|
| |
ComplexRendererFn -> ComplexRendererFns
Corrected a couple lingering references to tied operands that were missed.
llvm-svn: 316237
|
| |
|
|
| |
llvm-svn: 316236
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38977
llvm-svn: 316233
|
| |
|
|
| |
llvm-svn: 316228
|
| |
|
|
| |
llvm-svn: 316226
|
| |
|
|
|
|
|
|
|
|
|
| |
This was suggested in PR35003:
https://bugs.llvm.org/show_bug.cgi?id=35003
32-bit checks may be identical to 64-bit (if we avoid those pesky scalar params!).
I'll check in the script change shortly assuming this doesn't anger any bots.
llvm-svn: 316223
|
| |
|
|
|
|
| |
To help identify shuffle combine issues
llvm-svn: 316222
|
| |
|
|
| |
llvm-svn: 316220
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change comes from using lld for i686-windows-msvc. Before this change, lld
emits an error of:
error: relocation against symbol in discarded section: .xdata
It's possible that this could be addressed in lld, but I think this change is
reasonable on its own.
At a high level, this is being generated:
A (.text comdat) -> B (.text) -> C (.xdata comdat)
Where A is a C++ inline function, which references B, an exception handler
thunk, which references C, the exception handling info.
With this structure, lld will error when applying relocations to B if the C it
references has been discarded (some other C has been selected).
This change checks if A is comdat, and if so places the exception registration
thunk (B) in the comdata group of A (and B).
It appears that MSVC makes the __ehhandler function comdat.
Is it possible that duplicate thunks are being emitted into the final binary
with other linkers, or are they stripping the unused thunks?
Reviewers: rnk, majnemer, compnerd, smeenai
Reviewed By: rnk, compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38940
llvm-svn: 316219
|
| |
|
|
|
|
|
|
|
|
|
| |
Normally, if the registers holding the induction variable's bounds
are redefined inside of the loop's body, the loop cannot be converted
to a hardware loop. However, if the redefining instruction is actually
loading an immediate value into the register, this conversion is both
possible and legal (since the immediate itself will be used in the
loop setup in the preheader).
llvm-svn: 316218
|
| |
|
|
|
|
| |
We ignore the 32-bit/64-bit triple but I've tried to use i686 triples for CPUs that don't support x86_64
llvm-svn: 316217
|
| |
|
|
|
|
| |
Basic tests which are the equivalent of single-source shufflevector with variable mask.
llvm-svn: 316216
|
| |
|
|
|
|
|
| |
This reverts commit r314507, because the original patch is causing test
failures.
llvm-svn: 316215
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D39100
llvm-svn: 316214
|
| |
|
|
|
|
| |
As part of tracking down machine verifier issues (PR27481)
llvm-svn: 316213
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(recommit #2 after checking for timeout issue).
The original patch was an improvement to IR ValueTracking on
non-negative integers. It has been checked in to trunk (D18777,
r284022). But was disabled by default due to performance regressions.
Perf impact has improved. The patch would be enabled by default.
Reviewers: reames, hfinkel
Differential Revision: https://reviews.llvm.org/D34101
Patch by: Olga Chupina <olga.chupina@intel.com>
llvm-svn: 316208
|
| |
|
|
|
|
|
|
|
|
|
| |
This test checks that load from constant memory will be sunk regardless of
aliasing stores in the loop.
Patch by Daniil Suchkov!
Differential Revision: https://reviews.llvm.org/D39113
llvm-svn: 316207
|
| |
|
|
| |
llvm-svn: 316205
|
| |
|
|
|
|
|
| |
Will re-enable once I figure out why the necessary runtime functions are
missing on some bots.
llvm-svn: 316203
|
| |
|
|
|
|
| |
Turns on EmulatedTLS support by default in EngineBuilder. ;)
llvm-svn: 316200
|
| |
|
|
|
|
|
| |
The commit at https://reviews.llvm.org/rL315888 is causing some failures
with internal testing. Disabling this code until we can resolve the issues.
llvm-svn: 316199
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Updated the XRayExample docs with instructions for using the llvm-xray stacks
command.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39106
llvm-svn: 316192
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 316190
|