| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/ocb
This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.
llvm-svn: 337097
|
| |
|
|
|
|
|
|
|
|
| |
https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/azI
This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.
llvm-svn: 337096
|
| |
|
|
|
|
|
|
|
|
| |
https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/azI
This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.
llvm-svn: 337095
|
| |
|
|
|
|
| |
foldICmpWithLowBitMaskedVal()
llvm-svn: 337094
|
| |
|
|
|
|
| |
cf r337092
llvm-svn: 337093
|
| |
|
|
|
|
|
|
|
|
|
| |
sanitizer-x86_64-linux-fast
The bot has a /b directory, so /? matches against that and gets expanded to it.
(Thanks to Hans's r187366, which solved the same problem for clang-cl a while
ago and which saved me much head scratching.)
llvm-svn: 337092
|
| |
|
|
|
|
| |
For targets that have them off by default.
llvm-svn: 337091
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
liveness
The MachineOutliner was doing an std::for_each from the call (inserted
before the outlined sequence) to the iterator at the end of the
sequence.
std::for_each needs the iterator past the end, so the last instruction
was not taken into account when propagating the liveness information.
This fixes the machine verifier issue in machine-outliner-disubprogram.ll.
Differential Revision: https://reviews.llvm.org/D49295
llvm-svn: 337090
|
| |
|
|
|
|
|
|
|
| |
no conditions.
This is only valid to do if we're hardening calls and rets with LFENCE
which results in an LFENCE guarding the entire entry block for us.
llvm-svn: 337089
|
| |
|
|
|
|
|
|
| |
The code tried to find the immediate by using getNumOperands() on the MachineInstr, but there might be implicit-defs after the immediate that get counted.
Instead use getNumOperands() from the instruction description which will only count the operands that are defined in the td file.
llvm-svn: 337088
|
| |
|
|
| |
llvm-svn: 337087
|
| |
|
|
|
|
| |
https://reviews.llvm.org/D49319
llvm-svn: 337086
|
| |
|
|
| |
llvm-svn: 337085
|
| |
|
|
|
|
| |
https://reviews.llvm.org/D49318
llvm-svn: 337084
|
| |
|
|
|
|
|
|
|
|
| |
for size.
AVX512 doesn't have an immediate controlled blend instruction. But blend throughput is still better than movss/sd on SKX.
This commit changes AVX512 to use the AVX blend instructions instead of MOVSS/MOVSD. This constrains the register allocation since it won't be able to use XMM16-31, but hopefully the increased throughput and reduced port 5 pressure makes up for that.
llvm-svn: 337083
|
| |
|
|
|
|
| |
This reverts commit r337051.
llvm-svn: 337082
|
| |
|
|
|
|
|
| |
This reverts commits r337050 and r337059. Caused failure in
reverse-iteration bot that needs more investigation.
llvm-svn: 337081
|
| |
|
|
|
|
| |
This reverts commit r337076. Not needed any more.
llvm-svn: 337080
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r337021.
WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x1415cd65 in void write_signed<long>(llvm::raw_ostream&, long, unsigned long, llvm::IntegerStyle) /code/llvm-project/llvm/lib/Support/NativeFormatting.cpp:95:7
#1 0x1415c900 in llvm::write_integer(llvm::raw_ostream&, long, unsigned long, llvm::IntegerStyle) /code/llvm-project/llvm/lib/Support/NativeFormatting.cpp:121:3
#2 0x1472357f in llvm::raw_ostream::operator<<(long) /code/llvm-project/llvm/lib/Support/raw_ostream.cpp:117:3
#3 0x13bb9d4 in llvm::raw_ostream::operator<<(int) /code/llvm-project/llvm/include/llvm/Support/raw_ostream.h:210:18
#4 0x3c2bc18 in void printField<unsigned int, &(amd_kernel_code_s::amd_kernel_code_version_major)>(llvm::StringRef, amd_kernel_code_s const&, llvm::raw_ostream&) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:78:23
#5 0x3c250ba in llvm::printAmdKernelCodeField(amd_kernel_code_s const&, int, llvm::raw_ostream&) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:104:5
#6 0x3c27ca3 in llvm::dumpAmdKernelCode(amd_kernel_code_s const*, llvm::raw_ostream&, char const*) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:113:5
#7 0x3a46e6c in llvm::AMDGPUTargetAsmStreamer::EmitAMDKernelCodeT(amd_kernel_code_s const&) /code/llvm-project/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp:161:3
#8 0xd371e4 in llvm::AMDGPUAsmPrinter::EmitFunctionBodyStart() /code/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp:204:26
[...]
Uninitialized value was created by an allocation of 'KernelCode' in the stack frame of function '_ZN4llvm16AMDGPUAsmPrinter21EmitFunctionBodyStartEv'
#0 0xd36650 in llvm::AMDGPUAsmPrinter::EmitFunctionBodyStart() /code/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp:192
llvm-svn: 337079
|
| |
|
|
|
|
| |
post-load a register that isn't valid for use with OR or SHRX.
llvm-svn: 337078
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 337077
|
| |
|
|
|
|
|
| |
Add -debug-only=function-import to get more information for debugging
reverse-iteration bot failure from r337050.
llvm-svn: 337076
|
| |
|
|
| |
llvm-svn: 337075
|
| |
|
|
| |
llvm-svn: 337074
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If an HVX vector register is to be coalesced into a vector pair, make
sure that the vector pair will not have a function call in its live range,
unless it already had one. All HVX vector registers are volatile, so
any vector register live across a function call will have to be spilled.
If a vector needs to be spilled, and it's coalesced into a vector pair
then the whole pair will need to be spilled (even if only a part of it is
live), taking extra stack space.
llvm-svn: 337073
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
By looking at the callers of getUse(), we can see that even though
IVUsers may offer uses, but they may not be interesting to
LSR. It's possible that none of them is interesting.
Reviewers: sanjoy
Subscribers: jlebar, hiraditya, bixia, llvm-commits
Differential Revision: https://reviews.llvm.org/D49049
llvm-svn: 337072
|
| |
|
|
|
|
| |
Someone simultaneously fixed the breakage it was designed to fix.
llvm-svn: 337071
|
| |
|
|
|
|
| |
https://reviews.llvm.org/D49326
llvm-svn: 337070
|
| |
|
|
|
|
| |
Release Notes.
llvm-svn: 337069
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
That flag has been introduced in https://reviews.llvm.org/D48660 for
suppressing UIO error messages in an efficient way. The main motivation is to
be able to use UIO checks in builds used for fuzzing as it might provide an
interesting signal to a fuzzing engine such as libFuzzer.
See https://github.com/google/oss-fuzz/issues/910 for more information.
Reviewers: morehouse, kcc
Reviewed By: morehouse
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D49324
llvm-svn: 337068
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Ryzen has something like an 18 cycle latency on these based on Agner's data. AMD's own xls is blank. So it seems like there might be something tricky here.
Agner's data for Intel CPUs indicates these are a single uop there.
Probably safest to remove them. We never generate them without an intrinsic so this should be ok.
Differential Revision: https://reviews.llvm.org/D49315
llvm-svn: 337067
|
| |
|
|
|
|
|
|
|
|
| |
-Drop the intrinsic versions of conversion instructions. These should be handled when we do vectors. They shouldn't show up in scalar code.
-Add the float<->double conversions which were missing.
-Add the AVX512 and AVX version of the conversion instructions including the unsigned integer conversions unique to AVX512
Differential Revision: https://reviews.llvm.org/D49313
llvm-svn: 337066
|
| |
|
|
|
|
|
|
|
|
| |
-Move BSF/BSR to the same group as TZCNT/LZCNT/POPCNT.
-Split some of the bit manipulation instructions away from TZCNT/LZCNT/POPCNT. These are things like 'x & (x - 1)' which are composed of a few simple arithmetic operations. These aren't nearly as complicated/surprising as counting bits.
-Move BEXTR/BZHI into their own group. They aren't like a simple arithmethic op or the bit manipulation instructions. They're more like a shift+and.
Differential Revision: https://reviews.llvm.org/D49312
llvm-svn: 337065
|
| |
|
|
|
|
|
| |
It's a temporary decision until we reach out what causes
a failure.
llvm-svn: 337064
|
| |
|
|
| |
llvm-svn: 337063
|
| |
|
|
| |
llvm-svn: 337062
|
| |
|
|
| |
llvm-svn: 337061
|
| |
|
|
| |
llvm-svn: 337060
|
| |
|
|
|
|
| |
Should fix non-x86 bot failures for new test from r337050.
llvm-svn: 337059
|
| |
|
|
|
|
| |
support those tests.
llvm-svn: 337058
|
| |
|
|
|
|
|
|
| |
These were supposed to be integer types since we are selecting integer instructions.
Found while preparing to remove these patterns for another patch.
llvm-svn: 337057
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, rovka, kristof.beyls, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D46172
llvm-svn: 337056
|
| |
|
|
| |
llvm-svn: 337055
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This could simplify the isl iterator implementation a lot.
Reviewers: grosser, Meinersbur, bollu
Reviewed By: grosser
Subscribers: pollydev, llvm-commits
Differential Revision: https://reviews.llvm.org/D49019
llvm-svn: 337054
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When we're linking an alias which will be defined later, we neeed to
build a GlobalAlias, or else we'll crash later in
IRLinker::linkGlobalValueBody.
clang sometimes constructs aliases like this for C++ destructors.
Differential Revision: https://reviews.llvm.org/D49316
llvm-svn: 337053
|
| |
|
|
| |
llvm-svn: 337052
|
| |
|
|
|
|
|
| |
Clang change to reflect the FunctionsToImportTy type change
in the llvm changes for D48670.
llvm-svn: 337051
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to always import the same copy of a linkonce function,
even when encountering it with different thresholds (a higher one then a
lower one), keep track of the summary we decided to import.
This ensures that the backend only gets a single definition to import
for each GUID, so that it doesn't need to choose one.
Move the largest threshold the GUID was considered for import into the
current module out of the ImportMap (which is part of a larger map
maintained across the whole index), and into a new map just maintained
for the current module we are computing imports for. This saves some
memory since we no longer have the thresholds maintained across the
whole index (and throughout the in-process backends when doing a normal
non-distributed ThinLTO build), at the cost of some additional
information being maintained for each invocation of ComputeImportForModule
(the selected summary pointer for each import).
There is an additional map lookup for each callee being considered for
importing, however, this was able to subsume a map lookup in the
Worklist iteration that invokes computeImportForFunction. We also are
able to avoid calling selectCallee if we already failed to import at the
same or higher threshold.
I compared the run time and peak memory for the SPEC2006 471.omnetpp
benchmark (running in-process ThinLTO backends), as well as for a large
internal benchmark with a distributed ThinLTO build (so just looking at
the thin link time/memory). Across a number of runs with and without
this change there was no significant change in the time and memory.
(I tried a few other variations of the change but they also didn't
improve time or peak memory).
Reviewers: davidxl
Subscribers: mehdi_amini, inglorion, llvm-commits
Differential Revision: https://reviews.llvm.org/D48670
llvm-svn: 337050
|
| |
|
|
| |
llvm-svn: 337049
|
| |
|
|
|
|
|
|
| |
This reflects the fact that only ASTContext should ever create an
instance of BuiltinType, and matches what we do for all the other Type
subclasses.
llvm-svn: 337048
|