| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
extracting f64 and storing.
Summary: This is similar to what D52528 did for loads. It should match what generic type legalization does in 64-bit mode where it uses a v2i64 cast and an i64 store.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53173
llvm-svn: 344470
|
| |
|
|
|
|
| |
Follow-up to r344462.
llvm-svn: 344469
|
| |
|
|
| |
llvm-svn: 344468
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds two arguments to the main ExecutionSession::lookup method:
MatchNonExportedInJD, and MatchNonExported. These control whether and where
hidden symbols should be matched when searching a list of JITDylibs.
A similar effect could have been achieved by filtering search results, but
this would have involved materializing symbol definitions (since materialization
is triggered on lookup) only to throw the results away, among other issues.
llvm-svn: 344467
|
| |
|
|
|
|
| |
Improve codegen view as part of PR32655
llvm-svn: 344466
|
| |
|
|
|
|
| |
Improve codegen view as part of PR32655
llvm-svn: 344465
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Enhanced support for Z3 in the cmake configuration of clang; now it is possible to specify any arbitrary Z3 install prefix (CLANG_ANALYZER_Z3_PREFIX) to cmake with lib (or bin) and include folders. Before the patch only in cmake default locations
were searched (https://cmake.org/cmake/help/v3.4/command/find_path.html).
Specifying any CLANG_ANALYZER_Z3_PREFIX will force also CLANG_ANALYZER_BUILD_Z3 to ON.
Removed also Z3 4.5 version requirement since it was not checked, and now Clang works with Z3 4.7
Reviewers: NoQ, george.karpenkov, mikhail.ramalho
Reviewed By: george.karpenkov
Subscribers: rnkovacs, NoQ, esteffin, george.karpenkov, delcypher, ddcc, mgorny, xazax.hun, szepet, a.sidorin, Szelethus
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50818
llvm-svn: 344464
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Removed const qualifier from reset method of SMTSolver and Z3Solver objects.
Reviewers: mikhail.ramalho, george.karpenkov, NoQ, ddcc
Reviewed By: NoQ
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D52031
llvm-svn: 344463
|
| |
|
|
|
|
|
|
| |
The test was failing on e.g. PPC which can't target Windows. Fix by
requiring X86 target in the test. Also, make sure the output goes to a
temporary directory, since CWD may not be writable.
llvm-svn: 344462
|
| |
|
|
|
|
| |
The CTPOP case has been changed from VT.getSizeInBits to VT.getScalarSizeInBits - but this fits in with future work for vector support (PR32655) and doesn't affect any current (scalar) uses.
llvm-svn: 344461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PromoteIntRes_BITREVERSE if the shift amount is too large for the VT returned by getShiftAmountTy
Summary:
getShiftAmountTy for X86 returns MVT::i8. If a BSWAP or BITREVERSE is created that requires promotion and the difference between the original VT and the promoted VT is more than 255 then we won't able to create the constant.
This patch adds a check to replace the result from getShiftAmountTy to MVT::i32 if the difference won't fit. This should get legalized later when the shift is ultimately expanded since its clearly an illegal type that we're only promoting to make it a power of 2 bit width. Alternatively we could base the decision completely on the largest shift amount the promoted VT could use.
Vectors should be immune here because getShiftAmountTy always returns the incoming VT for vectors. Only the scalar shift amount can be changed by the targets.
Reviewers: eli.friedman, RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53232
llvm-svn: 344460
|
| |
|
|
| |
llvm-svn: 344459
|
| |
|
|
|
|
|
| |
This is a preliminary step to avoid regressions when we add
an actual 'fneg' instruction to IR. See D52934 and D53205.
llvm-svn: 344458
|
| |
|
|
|
|
|
|
|
|
| |
instead.
There is one remnant - AVX1 custom splitting of 256-bit vectors - which is due to a regression where the X86ISD::ANDNP is still performed as a YMM.
I've also tightened the CTLZ or CTPOP lowering in SelectionDAGLegalize::ExpandBitCount to require a legal CTLZ - it doesn't affect existing users and fixes an issue with AVX512 codegen.
llvm-svn: 344457
|
| |
|
|
|
|
|
| |
The tests with undef vector elements demonstrate a hole in
the current pattern matching.
llvm-svn: 344456
|
| |
|
|
| |
llvm-svn: 344455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes PR39177
Reviewers: spatel, jbuening
Reviewed By: jbuening
Subscribers: jbuening, llvm-commits
Differential Revision: https://reviews.llvm.org/D53129
llvm-svn: 344454
|
| |
|
|
|
|
|
|
| |
instead.
Adds CTTZ vector legalization support and begins the removal of the X86/SSE custom lowering.
llvm-svn: 344453
|
| |
|
|
|
|
| |
Use isConstantSplat instead of ISD::isConstantSplatVector to let us us peek through to illegal types (in this case for i686 targets to recognise i64 constants)
llvm-svn: 344452
|
| |
|
|
|
|
| |
The code in LowerScalarImmediateShift is just a more powerful version of ISD::isConstantSplatVector.
llvm-svn: 344451
|
| |
|
|
| |
llvm-svn: 344450
|
| |
|
|
| |
llvm-svn: 344449
|
| |
|
|
|
|
|
|
| |
If we have better CTLZ support than CTPOP, then use cttz(x) = width - ctlz(~x & (x - 1)) - and remove the CTTZ_ZERO_UNDEF handling as it no longer gives better codegen.
Similar to rL344447, this is also closer to LegalizeDAG's approach
llvm-svn: 344448
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the vector CTTZ lowering from:
cttz(x) = ctpop((x & -x) - 1)
to:
cttz(x) = ctpop(~x & (x - 1))
Not only does this make better use of the PANDN instruction, but it also matches the LegalizeDAG method which should allow us to remove the x86 specific code at some point in the future (we need to fix some issues with the bitcasted logic ops and CTPOP lowering first).
Differential Revision: https://reviews.llvm.org/D53214
llvm-svn: 344447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR39161)
Add shuffle lowering for the case where we can shuffle the lanes into place followed by an in-lane permute.
This is mainly for cases where we can have non-repeating permutes in each lane, but for now I've just enabled it for v4f64 unary shuffles to fix PR39161 - there is no test coverage for other shuffles that might benefit yet.
We now have several cross-lane shuffle lowering methods that all do something similar - I've looked at merging some of these (notably by making the repeated mask mechanism in lowerVectorShuffleByMerging128BitLanes optional), but there is a lot of assertions/assumptions in the way that makes this tricky - I ended up going for adding yet another relatively simple method instead.
Differential Revision: https://reviews.llvm.org/D53148
llvm-svn: 344446
|
| |
|
|
| |
llvm-svn: 344445
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Checking whether a functions throws indirectly may be very expensive because it
needs to visit its whole call graph. Therefore we should first check whether the
function is forbidden to throw and only check whether it throws afterward. This
also seems to solve bug https://bugs.llvm.org/show_bug.cgi?id=39167 where the
execution time is so long that it seems to hang.
Differential Revision: https://reviews.llvm.org/D53187
llvm-svn: 344444
|
| |
|
|
|
|
|
|
|
|
| |
In earlier Clang Static Analyzer versions `check::Bind() was not invoked for
parameter passing, so we needed a trick which is not needed anymore. However
add the tests to ensure its working.
Differential Revision: https::/reviews.llvm.org/D32906
llvm-svn: 344443
|
| |
|
|
|
|
|
|
| |
strlen(), size() or equal length"
This reverts commit r344374.
llvm-svn: 344442
|
| |
|
|
|
|
| |
This reverts commit r344379.
llvm-svn: 344441
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And also enable it by default to be consistent with e.g. modernize-use-using.
This improves consistency inside the check itself as well: both checks are now
disabled in macros by default.
This helps e.g. when running this check on client code where the macro is
provided by the system, so there is no easy way to modify it.
Reviewed By: alexfh
Differential Revision: https://reviews.llvm.org/D53217
llvm-svn: 344440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AArch64 can fold some shift+extend operations on the RHS operand of
comparisons, so swap the operands if that makes sense.
This provides a fix for https://bugs.llvm.org/show_bug.cgi?id=38751
Reviewers: efriedma, t.p.northover, javed.absar
Subscribers: mcrosier, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D53067
llvm-svn: 344439
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D52324 and D52764.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D52325
llvm-svn: 344438
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These new intrinsics have the semantics of the `minimum` and `maximum`
operations specified by the latest draft of IEEE 754-2018. Unlike
llvm.minnum and llvm.maxnum, these new intrinsics propagate NaNs and
always treat -0.0 as less than 0.0. `minimum` and `maximum` lower
directly to the existing `fminnan` and `fmaxnan` ISel DAG nodes. It is
safe to reuse these DAG nodes because before this patch were only
emitted in situations where there were known to be no NaN arguments or
where NaN propagation was correct and there were known to be no zero
arguments. I know of only four backends that lower fminnan and
fmaxnan: WebAssembly, ARM, AArch64, and SystemZ, and each of these
lowers fminnan and fmaxnan to instructions that are compatible with
the IEEE 754-2018 semantics.
Reviewers: aheejin, dschuff, sunfish, javed.absar
Subscribers: kristof.beyls, dexonsmith, kristina, llvm-commits
Differential Revision: https://reviews.llvm.org/D52764
llvm-svn: 344437
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D53172
llvm-svn: 344436
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The previous value looks Linux specific so that has been guarded with
the host OS being Linux.
On Apple platforms `%shared_libasan` expands to the absolute path of the
ASan dylib.
Previously on Linux `%shared_libasan` expanded to just the file name
of the shared library rather than the absolute path to the library.
This is likely a bug because it would rely on the OS's dynamic linker
to find the shared library which could accidentally pick up a system copy
rather than the shared library that was just built.
For other platforms we emit a warning if `config.asan_dynamic` is true.
This patch also only defines the substitution when `config.asan_dynamic`
is true because using this substitution only makes sense when the
dynamic library is available.
Reviewers: kubamracek, george.karpenkov, mgorny, phosek, etienneb, samsonov, kcc
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D53111
llvm-svn: 344434
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GetOrCreateFunctionComdat is currently used in SanitizerCoverage,
where it's defined. I'm planing to use it in HWASAN as well,
so moving it into a common location.
NFC
Reviewers: morehouse
Reviewed By: morehouse
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53218
llvm-svn: 344433
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SelectionDAGBuilder::visitShift will always zero-extend a shift amount when it
is promoted to the ShiftAmountTy. This results in zero-extension (masking)
which is unnecessary for RISC-V as the shift operations only read the lower 5
or 6 bits (RV32 or RV64).
I initially proposed adding a getExtendForShiftAmount hook so the shift amount
can be any-extended (D52975). @efriedma explained this was unsafe, so I have
instead eliminate the unnecessary and operations at instruction selection time
in a manner similar to X86InstrCompiler.td.
Differential Revision: https://reviews.llvm.org/D53224
llvm-svn: 344432
|
| |
|
|
| |
llvm-svn: 344431
|
| |
|
|
|
|
| |
.note.llvm.cgprofile was an obvious typo in rL333823
llvm-svn: 344430
|
| |
|
|
|
|
|
|
|
|
| |
This adds -- before any filenames, so that /U doesn't get interpreted
as a command line.
It also adds better error checking, so that we don't get assertions
on the failure path when a file fails to parse as a PDB.
llvm-svn: 344429
|
| |
|
|
|
|
| |
There's no guarantee that vector indices should use pointer types. So use the correct query method.
llvm-svn: 344428
|
| |
|
|
|
|
|
|
| |
- Removed redundant `llvm::`
- Typedef a long type name
- Initialize members by member initializers
llvm-svn: 344427
|
| |
|
|
|
|
|
| |
Fix line splitting logic to avoid sending empty lines to syslog, as
that adds extra newlines.
llvm-svn: 344426
|
| |
|
|
|
|
| |
avoid a stack stack temporary.
llvm-svn: 344425
|
| |
|
|
|
|
|
|
| |
(bitcast (f64))) by just emitting an EXTRACT_SUBVECTOR instead of a BUILD_VECTOR.
Generic legalization should be able to finish legalizing the EXTRACT_SUBVECTOR probably by turning it into a BUILD_VECTOR. But we should emit the simplest sequence.
llvm-svn: 344424
|
| |
|
|
|
|
|
|
| |
if the dest type can be widened by generic legalization. NFCI
The algorithm we would do previously was identical to generic legalization. If we ever switch to legalizing integer vectors via widening we'll be able to kill off the code since it now only runs for promotion.
llvm-svn: 344423
|
| |
|
|
|
|
|
|
|
|
| |
type, use a scalar_to_vector to turn the scalar into a vector intead of a build vector full of mostly undefs.
This is more consistent with what we usually do and matches some code X86 custom emits in some cases that I think I can cleanup.
The MIPS test change just looks to be an instruction ordering change.
llvm-svn: 344422
|
| |
|
|
| |
llvm-svn: 344421
|
| |
|
|
|
|
|
|
|
| |
Most of the time SIGPIPE is just annoying, and so we should
pass it on silently it by default.
<rdar://problem/39359145>
llvm-svn: 344418
|