[RISCV] Omit "@plt" in assembly output "call foo@plt" (#72467)

R_RISCV_CALL/R_RISCV_CALL_PLT distinction is not necessary and
R_RISCV_CALL has been deprecated. Since https://reviews.llvm.org/D132530

[RISCV] Omit "@plt" in assembly output "call foo@plt" (#72467)

R_RISCV_CALL/R_RISCV_CALL_PLT distinction is not necessary and
R_RISCV_CALL has been deprecated. Since https://reviews.llvm.org/D132530
`call foo` assembles to R_RISCV_CALL_PLT. The `@plt` suffix is not
useful and can be removed now (matching AArch64 and PowerPC).

GNU assembler assembles `call foo` to RISCV_CALL_PLT since 2022-09
(70f35d72ef04cd23771875c1661c9975044a749c).

Without this patch, unconditionally changing MO_CALL to MO_PLT could
create `jump .L1@plt, a0`, which is invalid in LLVM integrated assembler
and GNU assembler.

show more ...

[RISCV] Add a pass to rewrite rd to x0 for non-computational instrs whose return values are unused

When AMOs are used to implement parallel reduction operations, typically the return value would be

[RISCV] Add a pass to rewrite rd to x0 for non-computational instrs whose return values are unused

When AMOs are used to implement parallel reduction operations, typically the return value would be discarded.
This patch adds a peephole pass `RISCVDeadRegisterDefinitions`. It rewrites `rd` to `x0` when `rd` is marked as dead.
It may improve the register allocation and reduce pipeline hazards on CPUs without register renaming and OOO.
Comparison with GCC: https://godbolt.org/z/bKaxnEcec

Reviewed By: craig.topper

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

show more ...

[RISCV] Use LBU for extloadi8.

The Zcb extension has c.lbu, but not c.lb. This patch makes us
prefer LBU over LB if we have a choice which will enable more
compression opportunities.

Reviewed By: a

[RISCV] Use LBU for extloadi8.

The Zcb extension has c.lbu, but not c.lb. This patch makes us
prefer LBU over LB if we have a choice which will enable more
compression opportunities.

Reviewed By: asb

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

show more ...

[SelectionDAG] Do not second-guess alignment for alloca

Alignment of an alloca in IR can be lower than the preferred alignment
on purpose, but this override essentially treats the preferred
alignmen

[SelectionDAG] Do not second-guess alignment for alloca

Alignment of an alloca in IR can be lower than the preferred alignment
on purpose, but this override essentially treats the preferred
alignment as the minimum alignment.

The patch changes this behavior to always use the specified
alignment. If alignment is not set explicitly in LLVM IR, it is set to
DL.getPrefTypeAlign(Ty) in computeAllocaDefaultAlign.

Tests are changed as well: explicit alignment is increased to match
the preferred alignment if it changes output, or omitted when it is
hard to determine the right value (e.g. for pointers, some structs, or
weird types).

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

show more ...

[RISCV] Convert some tests to opaque pointers (NFC)

Revert "[SelectionDAG] Do not second-guess alignment for alloca"

Breaks amdgpu buildbot https://lab.llvm.org/buildbot/#/builders/193
23491

This reverts commit ffedf47d8b793e07317f82f9c2a5f5425ebb7

Revert "[SelectionDAG] Do not second-guess alignment for alloca"

Breaks amdgpu buildbot https://lab.llvm.org/buildbot/#/builders/193
23491

This reverts commit ffedf47d8b793e07317f82f9c2a5f5425ebb71ad.

show more ...

[SelectionDAG] Do not second-guess alignment for alloca

Alignment of an alloca in IR can be lower than the preferred alignment
on purpose, but this override essentially treats the preferred
alignmen

[SelectionDAG] Do not second-guess alignment for alloca

Alignment of an alloca in IR can be lower than the preferred alignment
on purpose, but this override essentially treats the preferred
alignment as the minimum alignment.

The patch changes this behavior to always use the specified
alignment. If alignment is not set explicitly in LLVM IR, it is set to
DL.getPrefTypeAlign(Ty) in computeAllocaDefaultAlign.

Tests are changed as well: explicit alignment is increased to match
the preferred alignment if it changes output, or omitted when it is
hard to determine the right value (e.g. for pointers, some structs, or
weird types).

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

show more ...

[RISCV] Make custom isel for (add X, imm) used by load/stores more selective.

Only handle immediates that would produce an ADDI or ADDIW of Lo12
as the final instruction in their materialization.

A

[RISCV] Make custom isel for (add X, imm) used by load/stores more selective.

Only handle immediates that would produce an ADDI or ADDIW of Lo12
as the final instruction in their materialization.

As the test change show this removes immediates that materialize
with lui+addiw that is not the same as lui+addi.

show more ...

[RISCV] Add tests for (load (add X, [2048,4094])). NFC

Offsets in the range [-4095,-2049] or [2048, 4094] are split into
two ADDIs. One of the ADDIs will be folded into the load/store
immediate thro

[RISCV] Add tests for (load (add X, [2048,4094])). NFC

Offsets in the range [-4095,-2049] or [2048, 4094] are split into
two ADDIs. One of the ADDIs will be folded into the load/store
immediate through an post-isel peephole.

show more ...

[RISCV] Add custom isel for (add X, imm) used by load/stores.

If the imm is out of range for an ADDI, we will materialize it in
a register using multiple instructions. If the ADD is used by a
load/s

[RISCV] Add custom isel for (add X, imm) used by load/stores.

If the imm is out of range for an ADDI, we will materialize it in
a register using multiple instructions. If the ADD is used by a
load/store, doPeepholeLoadStoreADDI can try to pull an ADDI from
the constant materialization into the load/store offset. This only
works if the ADD has a single use, otherwise the peephole would have
to rebuild multiple nodes.

This patch instead tries to solve the problem when the add is selected.
We check that the add is only used by loads/stores and if it is
we will select it to (ADDI (ADD X, Imm-Lo12), Lo12). This will enable
the simple case in doPeepholeLoadStoreADDI that can bypass an ADDI
used as a pointer. As a result we can remove the more complicated
peephole from doPeepholeLoadStoreADDI.

Reviewed By: reames

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

show more ...

[RISCV] Return false from isOffsetFoldingLegal instead of reversing the fold in lowering.

When lowering GlobalAddressNodes, we were removing a non-zero offset and
creating a separate ADD.

It alread

[RISCV] Return false from isOffsetFoldingLegal instead of reversing the fold in lowering.

When lowering GlobalAddressNodes, we were removing a non-zero offset and
creating a separate ADD.

It already comes out of SelectionDAGBuilder with a separate ADD. The
ADD was being removed by DAGCombiner.

This patch disables the DAG combine so we don't have to reverse it.
Test changes all look to be instruction order changes. Probably due
to different DAG node ordering.

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

show more ...

[RISCV] Fold addiw from (add X, (addiw (lui C1, C2))) into load/store address

This is a followup to D124231.

We can fold the ADDIW in this pattern if we can prove that LUI+ADDI
would have produced

[RISCV] Fold addiw from (add X, (addiw (lui C1, C2))) into load/store address

This is a followup to D124231.

We can fold the ADDIW in this pattern if we can prove that LUI+ADDI
would have produced the same result as LUI+ADDIW.

This pattern occurs because constant materialization prefers LUI+ADDIW
for all simm32 immediates. Only immediates in the range
0x7ffff800-0x7fffffff require an ADDIW. Other simm32 immediates
work with LUI+ADDI.

Reviewed By: asb

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

show more ...

[RISCV] Copy test from mem.ll to mem64.ll for completeness. NFC

Add nounwind to both copies.

Addresses post-commit feedback from f91690f7db96aae16425241a17fe6649f5d156b4

[RISCV] Merge addi into load/store as there is a ADD between them

This patch adds peephole optimizations for the following patterns:

(load (add base, (addi src, off1)), off2)
-> (load (add base,

[RISCV] Merge addi into load/store as there is a ADD between them

This patch adds peephole optimizations for the following patterns:

(load (add base, (addi src, off1)), off2)
-> (load (add base, src), off1+off2)
(store val, (add base, (addi src, off1)), off2)
-> (store val, (add base, src), off1+off2)

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

show more ...

[RISCV][test] Add explicit dso_local to definitions in ELF static relocation model tests

[RISCV] Switch to the Machine Scheduler

Most of the test changes are trivial instruction reorderings and differing
register allocations, without any obvious performance impact.

Differential Revisio

[RISCV] Switch to the Machine Scheduler

Most of the test changes are trivial instruction reorderings and differing
register allocations, without any obvious performance impact.

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

llvm-svn: 372106

show more ...

Revert Patch from Phabricator

This reverts r372092 (git commit e38695a0255c9e7b53639f349f8101bae1ce5c04)

llvm-svn: 372104

Patch from Phabricator

llvm-svn: 372092

[RISCV] Introduce codegen patterns for instructions introduced in RV64I

As discussed in the RFC
<http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, 64-bit
RISC-V has i64 as the on

[RISCV] Introduce codegen patterns for instructions introduced in RV64I

As discussed in the RFC
<http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, 64-bit
RISC-V has i64 as the only legal integer type. This patch introduces patterns
to support codegen of the new instructions
introduced in RV64I: addiw, addiw, subw, sllw, slliw, srlw, srliw, sraw,
sraiw, ld, sd.

Custom selection code is needed for srliw as SimplifyDemandedBits will remove
lower bits from the mask, meaning the obvious pattern won't work:

def : Pat<(sext_inreg (srl (and GPR:$rs1, 0xffffffff), uimm5:$shamt), i32),
(SRLIW GPR:$rs1, uimm5:$shamt)>;
This is sufficient to compile and execute all of the GCC torture suite for
RV64I other than those files using frameaddr or returnaddr intrinsics
(LegalizeDAG doesn't know how to promote the operands - a future patch
addresses this).

When promoting i32 sltu/sltiu operands, it would be more efficient to use
sign-extension rather than zero-extension for RV64. A future patch adds a hook
to allow this.

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

llvm-svn: 347973

show more ...