It's identical to SiFive7GetCyclesDefault.

Differential Revision: https://reviews.llvm.org/D155002

The most notable issue was producing v_mad_f32 in functions with the
dynamic mode, since it just ignores the mode. fdiv lowering is still
somewhat broken because it involves a mode switch and we need to query
the original mode.

I found that the newly added member variables, "EmitCompactUnwindNonCanonical" were not initialized in the constructor, but other member variables were initialized. The behavior seems to need to be consistent to improve code.

Reviewed By: oontvoo

Differential Revision: https://reviews.llvm.org/D154472

We were always printing "m1", we need to calculate the correct LMUL instead.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D153659

The implementations of a number of math functions on amdgpu involve
pre and post-scaling the inputs out of the denormal range. If these
are chained together we can possibly fold them out.

computeConstantRange seems weaker than computeKnownBits, so this
regresses some of the older vector tests.

A new Init type ArgumentInit is added to represent arguments.  We currently only support positional arguments; an upcoming change will add named argument support.

The index of argument in error message is removed.

Differential Revision: https://reviews.llvm.org/D154066

Fixes https://llvm.org/PR62082

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D154851

This is a preparation for

  P2093R14 Formatted output

When the output of print is to the terminal it needs to use the native
API. This means transcoding UTF-8 to UTF-16 on Windows. The encoder's
interface is modeled after

 P2728 Unicode in the Library, Part 1: UTF Transcoding

But only the required part for P2093R14 is implemented.

On Windows wchar_t is 16 bits, in order to test on platforms where
wchar_t is 32 bits the transcoder has support for char16_t. It also adds
and UTF-8 to UTF-32 encoder which is useful for other tests.

Note it is possible to use <codecvt> for transcoding, but that header is
deprecated. So rather write new code that is not deprecated; the hard
part, decoding, has already been done. The <codecvt> header also
requires locale support while the new code works without including
<locale>.

Note the current transcoder implementation can be optimized since it
basically does UTF-8 -> UTF-32 -> UTF-16. The first goal is to have a
working impleme...

Subnormal floating point numbers have a lower effective precision than
normal floating point numbers. This can cause issues for the fuzz test
since the MPFR floats have a constant precision regardless of the
exponent, and the precision must match exactly or else create rounding
errors. To solve this problem, the precision of the MPFR floats is
dynamically calculated.

Reviewed By: lntue

Differential Revision: https://reviews.llvm.org/D154909

This patch implements `llvm::PointerLikeTraits<FileEntryRef>` and `llvm::PointerLikeTraits<DirectoryEntryRef>`, allowing some simplifications around umbrella header/directory code.

Reviewed By: benlangmuir

Differential Revision: https://reviews.llvm.org/D154905

Reviewed By: paulkirth

Differential Revision: https://reviews.llvm.org/D154308

Currently the local builder used in IntrinsicCall doesn't have the
fastmath flags passed to it. This results in the fastmath attribute
not being added to certain runtime calls. This patch simply forwards
the fastmath flags from the parent builder.

Differential Revision: https://reviews.llvm.org/D154611

Otherwise if the current directory is not writable, we will fail with a
different message.

Use unsigned long in place of uint32_t for both clz and cls.

As far as I can tell this matches what ACLE defines and what gcc implements.

Noticed while investigating fixing https://github.com/llvm/llvm-project/issues/63113

Reviewed By: tmatheson

Differential Revision: https://reviews.llvm.org/D154910

These methods all take a `Stream *` to get feedback about what's going
on. By default, it's a nullptr, but we always feed it with a valid
pointer. It would therefore make more sense to have this take a
reference.

Differential Revision: https://reviews.llvm.org/D154883

After D154245 lands, we have greatly simplified the possible configurations for an entry in the RISCVMaskedPseudo table. This change goes through and reworks everything which uses that table to exploit the available simplifications.

To justify the correctness here, let me note that we no longer had any use of HasTU=true. We were left with only the HasTu=false, and IsCombined=true|false cases. The only usage is IsCombined=false was for the comparison operations. At the moment, these operations are the only ones in the table without vector policy operands. Instead of switching on the pseudo value, we can just check the VecPolicy flag instead.

It may be worth adding a passthru operand to the comparisons (which is actually needed to represent tail undefined vs tail agnostic), and a vector policy operand (which is strictly unneeded) just for consistency, but we can do that in a follow up patch for some further simplifica...

[clang][AIX] Fix Overly Strict LTO Option Checking against `data-sections` when `mxcoff-roptr` is in Effect

The LTO `-mxcoff-roptr` [[ https://github.com/llvm/llvm-project/blob/c6b2d25927817bdeca99653ee3e66720f33ce3ae/clang/lib/Driver/ToolChains/CommonArgs.cpp#L750 | check ]] against data sections is overly strict and it ignores the fact that [[ https://github.com/llvm/llvm-project/blob/c6b2d25927817bdeca99653ee3e66720f33ce3ae/llvm/lib/LTO/LTOCodeGenerator.cpp#L427 | data sections is on by default on AIX ]], causing valid LTO compilation to fail when `-fdata-sections` is not explicitly specified.

This patch revises the check so that an error is reported only if data sections is explicitly turned off for LTO.

Reviewed By: hubert.reinterpretcast

Differential Revision: https://reviews.llvm.org/D152021

A common thing to do is to call `str().c_str()` to get a null-terminated
string out of an existing StringRef. Most of the time this is to be able
to use a printf-style format string. However, llvm::formatv can handle
StringRefs without the need for the additional allocation. Using that
makes more sense.

Differential Revision: https://reviews.llvm.org/D154890

This change continues with the line of work discussed in https://discourse.llvm.org/t/riscv-transition-in-vector-pseudo-structure-policy-variants/71295.

This change handles most of the binary pseudos. I excluded pseudos which _TIED variants, and those that produce mask results. Both a bit different in functionality, and deserve their own change and review. As with previous changes in the series, we replace the existing TA and TU forms with a single unified pseudo with a passthru (which may be implicit_def) and a policy operand.

As before, we see codegen changes (some improvements and some regressions) due to scheduling differences caused by the extra implicit_def instructions.

Differential Revision: https://reviews.llvm.org/D154245

See D153632 and D154063

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-sanitized/4449/console

The register being replaced might have a more restrictive register
class due to requirements of the using instruction. We should
constrain the register class to preserve any restrictions.

This was found in our downstream on a custom instruction. I don't
have a test case for upstream currently.

Differential Revision: https://reviews.llvm.org/D154920

This reverts commit 4c6f95be

and relands e16c5c09

https://reviews.llvm.org/D154069

This is the counterpart to the forward dense dataflow analysis and
integrates into the dataflow framework. The implementation follows the
structure of existing dataflow analyses.

Reviewed By: Mogball, phisiart

Differential Revision: https://reviews.llvm.org/D154713

When an initializer value is missing for an allocatable component
in a structure constructor, the RHS is NULL() expression.
We should just skip this part of the initializer, since the component
must become unallocated (as it is from the initialization).
Runtime detected rank mismatch when we tried to pass NULL() box
RHS for assigning it to the unallocated component of rank 1, 2, etc.

Reviewed By: tblah

Differential Revision: https://reviews.llvm.org/D154906

In the context of elemental operation a dynamically optional
intrinsic argument must be lowered such that the elemental
designator is generated under isPresent check.

Reviewed By: tblah

Differential Revision: https://reviews.llvm.org/D154897

We need to explicitly mark DWARFUnitInfo as non-copyable since MSVC's
STL has a `noexcept(false)` move constructor for `unordered_map`; see
the added comment for more details.

An alternative might be using SmallVector instead of std::vector, since
that never tries to copy elements [1]. That would result in a bunch of
API changes though, so I figured a smaller targeted fix was better.

[1] https://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h

Reviewed By: ayermolo, maksfb

Differential Revision: https://reviews.llvm.org/D154924

There is no need to print the entire function after a transform via
LLVM_DEBUG statements.  These can be emulated via:
$ llc -print-after=consthoist -filter-print-funcs=<function name>

Otherwise, this makes the output of
$ llc -debug-only=consthoist
too verbose.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D154904

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D154239

A follow up to commit 6bad76c7 ("[Demangle] fix windows tests")
based on @thakis' report.

Fixes: #63740

Reviewed By: thakis

Differential Revision: https://reviews.llvm.org/D154875

Building on the support for wider input vector types from D154592, try to more aggressively widen inputs instead of scalarizing them.

Add support for `ieor` reduction operator in
OpenACC lowering.

Depends on D154887

Reviewed By: razvanlupusoru

Differential Revision: https://reviews.llvm.org/D154888

Add support for `ior` reduction operator in
OpenACC lowering.

Depends on D154886

Reviewed By: razvanlupusoru

Differential Revision: https://reviews.llvm.org/D154887

The 'RPCHandleTy' was intended to capture the intention that a specific
device owns its slot in the RPC server. However, this required creating
a temporary store to hold these pointers. This was causing really weird
spurious failure due to undefined behaviour in the order of library
teardown. For example, the x64 plugin would be torn down, set this to
some invalid memory, and then the CUDA plugin would crash. Rather than
spend the time to fully diagnose this problem I found it pertinent to
simply remove the failure mode.

This patch removes this indirection so now the usage of the RPC server
must always be done with the intended device. This just requires some
extra handling for the AMDGPU indirection where we need to store a
reference to the device.

Reviewed By: JonChesterfield

Differential Revision: https://reviews.llvm.org/D154971

On PowerPC, the vec_ct* builtin function take the form of eg. d=vec_cts(a,b)
LLVM (llc) will crash when a user specifies a number out of the allowed range
(0-31) for b.This patch truncates b so that we avoid the backend crash in some cases.

Further documentation for the builtins can be found here:
https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.0?topic=functions-vec-ctf
https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.0?topic=functions-vec-cts

Reviewed By: nemanjai, #powerpc

Differential Revision: https://reviews.llvm.org/D106409

Differential Revision: https://reviews.llvm.org/D154835

Add support for `iand` reduction operator in
OpenACC lowering.

Reviewed By: razvanlupusoru

Differential Revision: https://reviews.llvm.org/D154886

We were accidentally profiling the fabricated second argument (`0`),
resulting in overloaded dependent `a++` and non-overloaded dependent
`a++` having different hashes.

Port D69671 (llvm-readobj) to llvm-objdump. Add a class llvm::objdump::Dumper
and move some free functions into Dumper so that they can call
reportUniqueWarning.

Warnings seems preferable in these cases as the issue is localized and we can
continue dumping other information.

Differential Revision: https://reviews.llvm.org/D154754