GitLab

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

Identified with llvm-header-guard.

Identified with readability-redundant-member-init.

Identified with modernize-use-equals-default

Identified with readability-redundant-string-init.

Adds `-pagezero_size`. `-pagezero_size` commonly used for kernel development.
`-pagezero_size` changes the `__PAGEZERO` size, removing that segment if it is set to zero.

One of the four flags from {D118570}
Now with error messages and tests.

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

When the shift amount is known and a known sign bit analysis of
the shiftee indicates that no saturation will occur, then we can
replace SSHLSAT/USHLSAT by SHL.

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

It should be possible to replace SSHLSAT and USHLSAT with SHL when
it is known that no saturation will take place (e.g. by analysing
known sign bits in the first shift operand).

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

Revert rG7275de7f "[AArch64] translateLocChar - silence dead code warning"

Seems to cause some buildbot misbehaviour (+ there's a dumb copy+paste typo in the commit message....)

As suggested on D117898, we should be testing irregular _BitInt types with the __builtin_elementwise_* intrinsics

In scalarizeInstruction(), isUniformAfterVectorization is used to detect
cases where it is sufficient to always access the first lane. This
should map directly checking whether the operand is a uniform replicate
recipe.

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

Remove default case from switch and return None after the switch()

Remove default case from switch and move llvm_unreachable to after the switch()

This way they get lowered through the ARMISD::BUILD_VECTOR, which can
produce more efficient D register moves.

Also helps D115653 not get stuck in a loop.