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
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
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
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
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
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
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
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:
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
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
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
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
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
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
Summary:
Benchmarks for construct, copy, move, swap, destroy and invoke, with 8
different input states.
For the cases that matter, it tests with and without allowing constant
value propagation from construction into the operation tested.
This also adds helper functions to generate the cartesian product of
different configurations and generate benchmarks for all of them.
Reviewers: EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53087
llvm-svn: 344415
Enrico Steffinlongo