[mlir] Fix a warning
This patch fixes:
mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp:964:26:
error: missing 'typename' prior to dependent type name Op::Adaptor;
implicit 'typename' is a C++20 extension
[-Werror,-Wc++20-extensions]
[SPIR-V] Ensure that internal intrinsic functions for PHI's operand are inserted at the correct positions (#92316)
This PR is to ensure that internal intrinsic functions for PHI's operand
are inserted at the correct positions and don't break rules of
instruction domination and PHI nodes grouping at top of basic block.
TargetLibraryInfo: Assume no libcalls in the default constructor (#92400)
The only tricky point here is PlaceSafepoints has an awful hack where
it's creating a legacy PassManager inside it's runImpl, which was not
propagating the incoming TLI. This means there's an implicit bug fix,
where PlaceSafepoints would have been treating too many calls as
builtins.
I'm trying to delete the default constructor altogether, but this seems
to be more difficult.
Fix Tan inaccuracies on extreme complex inputs. (#92443)
Specifically, those with small/large absolute values. This ports
https://github.com/openxla/xla/pull/10525 and was verified with XLA's
test suite.
[AArch64][PAC] Fix creating check instructions for BBs without an epilog
`AArch64PAuth::checkAuthenticatedRegister()` splits the basic block
containing the tail call instruction to add check instructions, assuming
at least one more instruction before the call. This assumption is
incorrect in cases where some execution paths lead to the termination
block without creating the stack frame. This patch rearranges the
creation of the checks so that the prior splitting is not required.
[clang] Drop explicit conversions of string literals to StringRef (NFC)
We routinely rely on implicit conversions of string literals to
StringRef so that we can use operator==(StringRef, StringRef).
The LHS here are all known to be of StringRef.
[llvm] Drop explicit conversions of string literals to StringRef (NFC)
We routinely rely on implicit conversions of string literals to
StringRef so that we can use operator==(StringRef, StringRef).
[clang] Use constant rounding mode for floating literals (#90877)
Conversion of floating-point literal to binary representation must be
made using constant rounding mode, which can be changed using pragma
FENV_ROUND. For example, the literal "0.1F" should be representes by
either 0.099999994 or 0.100000001 depending on the rounding direction.
[CodeGen] Use operator==(StringRef, StringRef) (NFC)
The LHS and RHS are of SmallString and StringRef, respectively. We
can safely use operator==(StringRef, SringRef) with one implicit
conversion from SmallString to StringRef.
[JITLink][AArch64] Implement R_AARCH64_LDR_PREL_LO19 (#82172)
This relocation is used for the 32-bit aligned 21-bit immediate in LDR
Literal instructions.
[Flang][OpenMP]Missing convert to lhsType in atomic write (#92346)
Fixes test.f90 in #83144.
This issue is observed only when a boolean constant is assigned to a
logical variable. In non-openmp flow, a conversion op is inserted before
assigning it to a logical variable. This patch will insert a fir.convert
operation when the types are not the same, before generating the atomic
write operation.
I've proposed another patch(#85059 ) which removes checks at MLIR level
and looks like it's too permissive. I'm planning to abandon this patch
and address it here.
[lldb] Use operator==(StringRef, StringRef) instead of StringRef::equals (NFC) (#92476)
Note that StringRef::equals has been deprecated in favor of
operator==(StringRef, StringRef).
[BOLT][NFC] Rename DataAggregator::BranchInfo to TakenBranchInfo
Align the name to its counterpart `FTInfo` which avoids name aliasing
with llvm::bolt::BranchInfo and allows to drop namespace specifier.
Test Plan: NFC
Reviewers: maksfb, rafaelauler, ayermolo, dcci
Reviewed By: dcci
Pull Request: https://github.com/llvm/llvm-project/pull/92017
[LoongArch] Use sign extend for i32 arguments in makeLibCall on LA64
The 32 bits arguments and returns on LA64 are always sign extended to
i64. So we should be taking this into account around libcalls.
Reviewed By: heiher, SixWeining
Pull Request: https://github.com/llvm/llvm-project/pull/92375