| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This begins using the predicateinfo pass in NewGVN.
Reviewers: davide
Subscribers: llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D29682
llvm-svn: 295583
|
| |
|
|
|
|
| |
shouldSwapOperands to be correct.
llvm-svn: 295582
|
| |
|
|
|
|
| |
helpers, and fixing support for the renaming the comparison.
llvm-svn: 295581
|
| |
|
|
| |
llvm-svn: 295580
|
| |
|
|
|
|
|
|
| |
parameters instead of doing 128-bit and 256-bit simultaneously.
This requires some instructions to be renamed to move the Y earlier in the instruction name. The new names are more consistent with other instructions.
llvm-svn: 295579
|
| |
|
|
|
|
| |
gcc only allows you to mix enums / ints if they have the same signedness.
llvm-svn: 295577
|
| |
|
|
|
|
| |
gcc only allows you to mix enums / ints if they have the same signedness.
llvm-svn: 295576
|
| |
|
|
|
|
| |
Added assertion to check input type of X86ISD::VZEXT during target known bits calculation.
llvm-svn: 295575
|
| |
|
|
|
|
|
|
|
| |
Changing to 'or' (rather than 'xor' when no wrapping flags are set)
allows icmp simplifies to happen as expected.
Differential Revision: https://reviews.llvm.org/D29729
llvm-svn: 295574
|
| |
|
|
|
|
|
|
|
| |
The change to InstCombine in:
https://reviews.llvm.org/D29729
...exposes this missing fold in InstSimplify, so adding this
first to avoid a regression.
llvm-svn: 295573
|
| |
|
|
|
|
| |
Clang has now been fixed to not use these intrinsics.
llvm-svn: 295571
|
| |
|
|
|
|
|
| |
This is the same transform that is current used for:
select Bool, 0, -1
llvm-svn: 295568
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
2 small fixes extracted from
https://reviews.llvm.org/D29064
Reviewers: kuhar, davide, dberlin, george.burgess.iv
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30109
llvm-svn: 295566
|
| |
|
|
|
|
| |
This reverts r295564. I missed that clang was still using the intrinsics despite our half implemented autoupgrade support.
llvm-svn: 295565
|
| |
|
|
|
|
| |
It seems we were already upgrading 128-bit VPCMOV, but the intrinsic was still defined and being used in isel patterns. While I was here I also simplified the tablegen multiclasses.
llvm-svn: 295564
|
| |
|
|
| |
llvm-svn: 295563
|
| |
|
|
| |
llvm-svn: 295562
|
| |
|
|
|
|
| |
This was accepting GFX9 instructions on VI.
llvm-svn: 295557
|
| |
|
|
| |
llvm-svn: 295555
|
| |
|
|
| |
llvm-svn: 295554
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several visitors check if operands to the instruction are constants,
either as it is or after looking up SimplifiedValues, check if the
result is a constant and update the SimplifiedValues map. This
refactoring splits it into a common function that does the checking of
whether the operands are constants and updating of the SimplifiedValues
table, and an instruction specific part that is implemented by each
instruction visitor as a lambda and passed to the common function.
Differential revision: https://reviews.llvm.org/D30104
llvm-svn: 295552
|
| |
|
|
|
|
| |
legacy unmasked intrinsics and select instructions.
llvm-svn: 295543
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29792
llvm-svn: 295539
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The default threshold for fully unroll is too conservative. This patch doubles the full-unroll threshold
This change will affect the following speccpu2006 benchmarks (performance numbers were collected from Intel Sandybridge):
Performance:
403 0.11%
433 0.51%
445 0.48%
447 3.50%
453 1.49%
464 0.75%
Code size:
403 0.56%
433 0.96%
445 2.16%
447 2.96%
453 0.94%
464 8.02%
The compiler time overhead is similar with code size.
Reviewers: davidxl, mkuper, mzolotukhin, hfinkel, chandlerc
Reviewed By: hfinkel, chandlerc
Subscribers: mehdi_amini, zzheng, efriedma, haicheng, hfinkel, llvm-commits
Differential Revision: https://reviews.llvm.org/D28368
llvm-svn: 295538
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we happened to visit twice, one when scanning
MDNodes and the other one while visiting the function. Remove
the explicit call to visitDISubprogram there, so we don't emit
the same error twice in case the verifier fail and we save some
time when running it.
Thanks to Justin Bogner for the report and Adrian for the quick
review!
PR: 31995
llvm-svn: 295537
|
| |
|
|
| |
llvm-svn: 295535
|
| |
|
|
|
|
|
|
| |
This avoids creating a DILocation just to represent a line number,
since creating Metadata is expensive. Creating a DiagnosticLocation
directly is much cheaper.
llvm-svn: 295531
|
| |
|
|
|
|
|
| |
In an effort to generalize this so it can be used by more than
just PDB code, we shouldn't assume little endian.
llvm-svn: 295525
|
| |
|
|
|
|
|
|
|
| |
This creates and uses a DiagnosticLocation type rather than using
DebugLoc for this purpose in the backend diagnostics. This is NFC for
now, but will allow us to create locations for diagnostics without
having to create new metadata nodes when we don't have a DILocation.
llvm-svn: 295519
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Adapt MachineBasicBlock::getName() to have the same behavior as the IR
BasicBlock (Value::getName()).
- Add it to lib/CodeGen/CodeGen.cpp::initializeCodeGen so that it is linked in
the CodeGen library.
- MachineRegionInfoPass's name conflicts with RegionInfoPass's name ("region").
- MachineRegionInfo should depend on MachineDominatorTree,
MachinePostDominatorTree and MachineDominanceFrontier instead of their
respective IR versions.
- Since there were no tests for this, add a X86 MIR test.
Patch by Francis Visoiu Mistrih<fvisoiumistrih@apple.com>
llvm-svn: 295518
|
| |
|
|
|
|
|
|
| |
A line number doesn't make much sense if you don't say where it's
from. Add a verifier check for this and update some tests that had
bogus debug info.
llvm-svn: 295516
|
| |
|
|
|
|
|
|
|
|
|
| |
When promoting the Load of a Store-Load pair to a COPY all kill flags
between the store and the load need to be cleared.
rdar://30402435
Differential Revision: https://reviews.llvm.org/D30110
llvm-svn: 295512
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Newer ppc supports unaligned memory access, it reduces the cost of unaligned memory access significantly. This patch handles this case in PPCTTIImpl::getMemoryOpCost.
This patch fixes pr31492.
Differential Revision: https://reviews.llvm.org/D28630
This is resubmit of r292680, which was reverted by r293092. The internal application failures were actually caused by a source code bug.
llvm-svn: 295506
|
| |
|
|
| |
llvm-svn: 295505
|
| |
|
|
|
|
| |
Reapply r295371 with a fix for the Windows bot failures.
llvm-svn: 295504
|
| |
|
|
| |
llvm-svn: 295503
|
| |
|
|
| |
llvm-svn: 295502
|
| |
|
|
| |
llvm-svn: 295500
|
| |
|
|
|
|
| |
other minor fixes (NFC).
llvm-svn: 295499
|
| |
|
|
| |
llvm-svn: 295493
|
| |
|
|
|
|
| |
Fixes PRPR31309
llvm-svn: 295492
|
| |
|
|
| |
llvm-svn: 295489
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A future change will cause this byte offset to be inttoptr'd and then exported
via an absolute symbol. On the importing end we will expect the symbol to be
in range [0,2^32) so that it will fit into a 32-bit relocation. The problem
is that on 64-bit architectures if the offset is negative it will not be in
the correct range once we inttoptr it.
This change causes us to use a 32-bit integer so that it can be inttoptr'd
(which zero extends) into the correct range.
Differential Revision: https://reviews.llvm.org/D30016
llvm-svn: 295487
|
| |
|
|
|
|
|
|
|
|
| |
This fixes PR31381, which caused an assertion and/or invalid debug info.
This affects debug variables that have multiple fragments in the MMI
side (i.e.: in the stack frame) table.
rdar://problem/30571676
llvm-svn: 295486
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: jmolloy, t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D30097
llvm-svn: 295478
|
| |
|
|
|
|
|
| |
The mem operand is used by GlobalISel to convey atomic constraints so dropping
it is invalid.
llvm-svn: 295476
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This set of patches adds support for Cavium ThunderX ARM64 processors:
* ThunderX
* ThunderX T81
* ThunderX T83
* ThunderX T88
Patch by Stefan Teleman
Differential Revision: https://reviews.llvm.org/D28891
llvm-svn: 295475
|
| |
|
|
|
|
|
|
|
|
| |
functions are readnone.
The goal is to get an analysis result even for de-refineable functions.
Differential Revision: https://reviews.llvm.org/D29803
llvm-svn: 295472
|
| |
|
|
|
|
|
| |
This generalizes the name in preparation for decoupling the concept
from DebugLoc.
llvm-svn: 295465
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC link.exe cannot handle associative sections that refer later
sections in the section header. Technically, such COFF object doesn't
violate the Microsoft COFF spec, as the spec doesn't say anything
about that, but still we should avoid doing that to make it compatible
with MS tools.
This patch assigns smaller section numbers to non-associative sections
and larger numbers to associative sections. This should resolve the
compatibility issue.
Differential Revision: https://reviews.llvm.org/D30080
llvm-svn: 295464
|