[RISCV] Enable bidirectional scheduling and tracking register pressure (#115445)


This is based on other targets like PPC/AArch64 and some experiments.

This PR will only enable bidirectional schedu

[RISCV] Enable bidirectional scheduling and tracking register pressure (#115445)


This is based on other targets like PPC/AArch64 and some experiments.

This PR will only enable bidirectional scheduling and tracking register
pressure.

Disclaimer: I haven't tested it on many cores, maybe we should make
some options being features. I believe downstreams must have tried
this before, so feedbacks are welcome.

show more ...

[RISCV][LSR] Account for temporary register for base addition (#92296)

An LSR formula may require the addition of multiple base or scale
registers, this sum reduction requires a temporary register

[RISCV][LSR] Account for temporary register for base addition (#92296)

An LSR formula may require the addition of multiple base or scale
registers, this sum reduction requires a temporary register to perform.
Since the formulas are independent, we only need one temporary,
regardless of the number of unique formula. Each formula can reuse the
same temporary. A later CSE pass may come along and combine
sub-expressions - but then the register pressure would be that passes
problem to consider.

This change fixes up the costing in the RISCV specific way, but this is
really a generic LSR problem. I just didn't feel like fighting with LSR
and dealing with all the various targets swinging slightly in hard to
reason about ways. This problem is more pronounced on RISCV than any
other target due to our lack of addressing modes.

This change is not hugely important on it's own, but I have an upcoming
change to add support fo shNadd in LSR which biases us fairly strongly
towards adding more "base adds". Without this change, we see net
regression due to the increase in register pressure which is not
accounted for.

show more ...

[RISCV][LSR] Treat number of instructions as dominate factor in LSR cost decisions

This matches the behavior from a number of other targets, including e.g. X86. This does have the effect of increasi

[RISCV][LSR] Treat number of instructions as dominate factor in LSR cost decisions

This matches the behavior from a number of other targets, including e.g. X86. This does have the effect of increasing register pressure slightly, but we have a relative abundance of registers in the ISA compared to other targets which use the same heuristic.

The motivation here is that our current cost heuristic treats number of registers as the dominant cost. As a result, an extra use outside of a loop can radically change the LSR result. As an example consider test4 from the recently added test/Transforms/LoopStrengthReduce/RISCV/lsr-cost-compare.ll. Without a use outside the loop (see test3), we convert the IV into a pointer increment. With one, we leave the gep in place.

The pointer increment version both decreases number of instructions in some loops, and creates parallel chains of computation (i.e. decreases critical path depth). Both are generally profitable.

Arguably, we should really be using a more sophisticated model here - such as e.g. using profile information or explicitly modeling parallelism gains. However, as a practical matter starting with the same mild hack that other targets have used seems reasonable.

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

show more ...

[RISCV] Convert test to opaque pointers (NFC)

There is a minor change in operand order (of a commutative
instruction).

[RISCV] Adjust RV64I data layout by using n32:64 in layout string

Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.

By adding n32 to

[RISCV] Adjust RV64I data layout by using n32:64 in layout string

Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.

By adding n32 to the DataLayout string, middle end optimizations will consider i32 to be a native type. One known effect of this is enabling LoopStrengthReduce on loops with i32 induction variables. This can be beneficial because C/C++ code often has loops with i32 induction variables due to the use of `int` or `unsigned int`.

If this patch exposes performance issues, those are better addressed by tuning LSR or other passes.

Reviewed By: asb, frasercrmck

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

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] Add initial test coverage for LSR

Establish the most basic possible test coverage for LSR transformation on RISCV.

Original patch by eopXD (D123458), modified by me to cleanup/simplify test

[RISCV] Add initial test coverage for LSR

Establish the most basic possible test coverage for LSR transformation on RISCV.

Original patch by eopXD (D123458), modified by me to cleanup/simplify tests.

show more ...