Index of vset/vget must be a constant integer and be
located in right range.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D122629
We started diagnosing this situation with a more clear diagnostic
message, but it was pointed out that unevaluated contexts don't really
have the undefined behavior property as there is no runtime access
involved.
This augments the changes in https://reviews.llvm.org/D122656 to not
diagnose in an unevaluated context.
This reverts commit 115b3ace36.
Starting from this commit the buildbot sanitizer-x86_64-linux-bootstrap-msan
starts failing (build 10071). Reverted for investigation.
Insts must be destroyd before xParent
or it can read it with stack like this:
0 in llvm::MachineInstr::getMF() const MachineInstr.cpp:637:3
1 in getMF MachineInstr.h:302:50
2 in removeNodeFromList MachineBasicBlock.cpp:163:32
While this claims to be the base class for fixed and scalable
vectors, this is no longer the case since D94405. In fact,
LLVMVectorType is not usable, since the methods it declares are
never defined. Remove this leftover.
Differential Revision: https://reviews.llvm.org/D122707
Allow conversion of a diagnostic to FailureOr. This conversion only results
in `failure` because in the case where operator LogicalResult would return
success, the FailureOr constructor would assert.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D122596
If we're not relying on the flag result, we can fold the constants together into the RHS immediate operand and set the LHS operand to zero, simplifying for further folds.
We could do something similar if the flag result is in use and the constant fold doesn't affect it, but I don't have any real test cases for this yet.
As suggested by @davezarzycki on Issue #35256
Differential Revision: https://reviews.llvm.org/D122482
Based off the script from D103695, we were exaggerating the cost of the v2i64 comparison expansion using instruction count instead of effective throughput
The op documentation of the ops of the scf dialect used /**/ style block
comments which doesn't seem to exists (anymore?).
Reviewed By: nicolasvasilache, ingomueller-net
Differential Revision: https://reviews.llvm.org/D122565
In D122512, several masked patterns were added to support lowering of
vector-predicated float-to-int and int-to-float conversions. With the
introduction of these patterns, all of the old "unmasked" patterns are
matchable via the DAG post-process introduced in D118810, once the relevant
opcode entries are set up in the helper table.
Locally this reduces the generated isel table by 4%.
Reviewed By: arcbbb
Differential Revision: https://reviews.llvm.org/D122637
This is an alternative to D122376. Rather than working around the
problem, this patch requires that struct return types in intrinsics
are anonymous/literal and adds auto-upgrade code to convert
existing uses of intrinsics with named struct types.
This ensures that the mapping between intrinsic name and
intrinsic function type is actually bijective, as it is supposed
to be.
This also fixes https://github.com/llvm/llvm-project/issues/37891.
Differential Revision: https://reviews.llvm.org/D122471
See f10cee91ae. The test did still not run successful since the
`CHECK-MESSAGE` line is still read and considered even though the `#ifdef` removes the code if
`__int128_t` is not available. Now there is a fallback type in this case.
A new function 'getConstrainedIntrinsic' is added, which for any gived
instruction returns id of the corresponding constrained intrinsic. If
there is no constrained counterpart for the instruction or the instruction
is already a constrained intrinsic, the function returns zero.
Differential Revision: https://reviews.llvm.org/D69562
Includes 2 corrections:
* Update irreducible control flow and add references to CycleTerminology;
Natural loop is not the only definition of something looping in LLVM anymore.
* Mention mustprogress loop and function attributes to be used
instead of the llvm.sideeffect intrinsic.
This patch add some tests to show some optimization opportunities
for bitreverse-shift.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D121507
masked compare and vmsbf/vmsif/vmsof are always tail agnostic, we could
check maskedoff value to decide mask policy rather than have a addtional
policy operand.
Reviewed By: craig.topper, arcbbb
Differential Revision: https://reviews.llvm.org/D122456
This reverts commit 10fd2822b7.
I have a better implementation for those operations without the
additional policy operand.
masked compare and vmsbf/vmsif/vmsof are always tail agnostic so we could
assume undef maskedoff is mask agnostic.
Differential Revision: https://reviews.llvm.org/D122455
This is a re-land of https://reviews.llvm.org/D86171 with fix.
Fuchsia's system libraries are instrumented and use the lsan
allocator for internal purposes. So leak checking needs to run
after all atexit hooks and after the system libraries' internal
exit-time hooks. The <zircon/sanitizer.h> hook API calls the
__sanitizer_process_exit_hook function at exactly the right time.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D88248
In the previous patch adding -mfma to functions that need it for windows
builds I missed log2f.
Differential Revision: https://reviews.llvm.org/D122693
On Windows the functions that use fma don't properly include the fma
intrinsics unless -mfma is added to the compile options. This patch adds
the compile option to all of the functions that need it.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D122689
Previously, the "fsqrt" instruction was used on all x86_64 platforms
for finding the square root of long doubles. On long double is double
platforms (e.g. windows) this created errors. This patch changes square
root function for long doubles to be the same as the one for doubles if
long doubles are doubles.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D122688
Also, check that NRVO currently isn't performed in test25. The checks
were accidentally removed when https://reviews.llvm.org/D122425 disabled
inlining.
HLSL uses Microsoft-style attributes `[attr]`, which clang mostly
ignores. For HLSL we need to handle known Microsoft attributes, and to
maintain C/C++ as-is we ignore unknown attributes.
To utilize this new code path, this change adds the HLSL `numthreads`
attribute.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D122627
clang: <root>/clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:727:
void assertEqualBitWidths(clang::ento::ProgramStateRef,
clang::ento::Loc, clang::ento::Loc): Assertion `RhsBitwidth ==
LhsBitwidth && "RhsLoc and LhsLoc bitwidth must be same!"'
This change adjusts the bitwidth of the smaller operand for an evalBinOp
as a result of a comparison operation. This can occur in the specific
case represented by the test cases for a target with different pointer
sizes.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D122513
Delyan Kratunov reported an issue where __builtin_memcmp is
not inlined into simple load/compare instructions.
This is a known issue. In the current state, __builtin_memcmp
will be converted to memcmp call which won't work for
bpf programs.
This patch added support for expanding __builtin_memcmp with
actual loads and compares up to currently maximum 128 total loads.
The implementation is identical to PowerPC.
Differential Revision: https://reviews.llvm.org/D122676
In some case, like in the added test case, we can reach
selectInterleaveCount with loops that actually have a cost of 0.
Unfortunately a loop cost of 0 is also used to communicate that the cost
has not been computed yet. To resolve the crash, bail out if the cost
remains zero after computing it.
This seems like the best option, as there are multiple code paths that
return a cost of 0 to force a computation in selectInterleaveCount.
Computing the cost at multiple places up front there would unnecessarily
complicate the logic.
Fixes#54413.
Add include to resolve compiler warning about no previous extern declaration for non-static HashAlgorithm
Differential Revision: https://reviews.llvm.org/D122630
