If we're trying to reserve more memory than bits in the stream,
reject this early to avoid OOM.

AbstractConverter private variable is currently not used
and triggers a buildbot failure.

https://lab.llvm.org/buildbot/#/builders/180/builds/3119

This fixes the buildbot.

For most builtins, `__purefn` always comes after `__ovld`, but the
read_image functions did not follow this pattern.

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

Similar to 60cc1d32 for NetBSD, add aliases and interceptors for the
following pthread related functions:

- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(3)
- pthread_rwlock_init(3)
- pthread_rwlock_destroy(3)
- pthread_rwlock_rdlock(3)
- pthread_rwlock_tryrdlock(3)
- pthread_rwlock_wrlock(3)
- pthread_rwlock_trywrlock(3)
- pthread_rwlock_unlock(3)
- pthread_once(3)
- pthread_sigmask(3)

In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.

ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.

Reviewed By: dvyukov

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

Tidier solution to the unused variable warnings - we already do this in other places in this file.

There are kinds of inline asm constraints and corresponding register class or register as following.

 'b': mGPRRegClass
 'v': sGPRRegClass
 'w': sFPR32RegClass or sFPR64RegClass
 'c': C register
 'z': R14 register
 'h': HI register
 'l': LO register
 'y': HI or LO register

It also adds codegen test for inline-asm including constraints, clobbers and abi names.

Add PR41749 test coverage

Avoid report_fatal_error(), propagate the error upwards instead.

Inspired by the discussion on D118694, this adds a straightforward
fuzzer for bitcode reading. Currently it will very quickly run into
OOM, because we do unconditional vector reservations with
user-provided sizes.

Similar to D116843 for Gnu.cpp

Reviewed By: MaskRay

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

Reviewed By: bader

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

A variable was used within assert() only.

Depends on D118978.

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

This patch add lowering for simple local variable.

- The signatures in `ConvertType.h` have been simplified to take advantage of the `AbstractConverter`.
- The lowering make use of the `allocateLocal` from the `FirOpBuilder`.

This lowering is used in patch D118982

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: kiranchandramohan, jeanPerier, schweitz

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

Use range base loop loop to improve code readability.

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

In D116573, the relocation behavior of R_RISCV_BRANCH didn't consider that branch instruction like 'bge' has a branch target address which is given as a PC-relative offset, sign-extend and multiplied by 2.
Although the target address is a 12-bits number, acctually its range is [-4096, 4094].

This patch fix it.

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

Enhance to fold csel into csinc instruction.
Fix https://github.com/llvm/llvm-project/issues/53071

Reviewed By: dmgreen

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

This is both more efficient and more ergonomic to use, as inverting a
bit vector is trivial while inverting a set is annoying.

Sadly this leaks into a bunch of APIs downstream, so adapt them as well.

This would be NFC, but there is an ordering dependency in MemRefOps's
computeMemRefRankReductionMask. This is now deterministic, previously it
was dependent on SmallDenseSet's unspecified iteration order.

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

This dialect is intended to model lower level/branch based control-flow constructs. The initial set
of operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the current
standard dialect.

See https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061

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

Depends On D119025

Reviewed By: frgossen

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

Enabled loop interchange support for floating point reductions
if it is allowed to reorder floating point operations.

Previously when we encouter a floating point PHI node in the
outer loop exit block, we bailed out since we could not detect
floating point reductions in the early days. Now we remove this
limiation since we are able to detect floating point reductions.

Reviewed By: #loopoptwg, Meinersbur

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

Rename the SelfMultiply argument to make it clearer that the argument must not be undef

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

As raised by @efriedma on D117995 - the source must not be undef to demand any bits in mul(x,x) other than bit[1]

https://alive2.llvm.org/ce/z/Cxkjen

rv64izbb has a RORW/ROLW instructions that operate on the lower
32-bits of a 64-bit value and sign extend bit 31 of the result.

DAGCombiner won't match rotate idioms because the i32 type isn't Legal
on riscv64.

This patch teaches DAGCombiner to allow it if the type is going to
be promoted and the target has Custom type legalization for ISD::ROTL
or ISD::ROTR. I've restricted this to scalar types. It doesn't appear
any in tree targets other than riscv64 have custom type legalization
for rotates.

If this patch isn't acceptable, I guess I can match SRLW, SLLW, and OR
after type legalization, but I'd like to avoid that if possible.

Reviewed By: RKSimon

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