Nicolai Hähnle 52bc2e7577 [AMDGPU][SelectionDAG] Don't combine uniform multiplies to MUL_[UI]24
Prefer to keep uniform (non-divergent) multiplies on the scalar ALU when
possible. This significantly improves some game cases by eliminating
v_readfirstlane instructions when the result feeds into a scalar
operation, like the address calculation for a scalar load or store.

Since isDivergent is only an approximation of whether a value is in
SGPRs, it can potentially regress some situations where a uniform value
ends up in a VGPR. These should be rare in real code, although the test
changes do contain a number of examples.

Most of the test changes are just using s_mul instead of v_mul/mad which
is generally better for both register pressure and latency (at least on
GFX10 where sgpr pressure doesn't affect occupancy and vector ALU
instructions have significantly longer latency than scalar ALU). Some
R600 tests now use MULLO_INT instead of MUL_UINT24.

GlobalISel appears to handle more scenarios in the desirable way,
although it can also be thrown off and fails to select the 24-bit
multiplies in some cases.

Alternative solution considered and rejected was to allow selecting
MUL_[UI]24 to S_MUL_I32. I've rejected this because the definition of
those SD operations works is don't-care on the most significant 8 bits,
and this fact is used in some combines via SimplifyDemandedBits.

Based on a patch by Nicolai Hähnle.

Differential Revision: https://reviews.llvm.org/D97063
2021-02-23 15:39:19 +00:00
..
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2019-06-20 15:08:34 +00:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-08-09 20:50:30 +02:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-08-09 20:50:30 +02:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2019-07-01 17:17:45 +00:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-09-14 13:40:17 +01:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-19 15:05:25 +00:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-08-05 12:36:26 -07:00
2020-08-05 12:36:26 -07:00
2021-02-17 16:01:32 -08:00
2020-06-15 16:18:05 -07:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-06-15 16:18:05 -07:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-01-21 10:51:36 -05:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-08-09 20:50:30 +02:00
2020-06-25 10:38:23 +02:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2021-02-17 16:01:32 -08:00
2020-08-09 20:50:30 +02:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-10-22 12:54:35 -04:00
2021-02-17 16:01:32 -08:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2020-06-04 17:49:00 -04:00
2019-06-20 15:08:34 +00:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-04-03 10:07:21 +01:00
2020-08-09 20:50:30 +02:00
2021-02-17 16:01:32 -08:00
2020-08-09 20:50:30 +02:00
2020-06-15 16:18:05 -07:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-08-09 20:50:30 +02:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2021-02-17 16:01:32 -08:00
2020-01-12 22:44:51 -05:00

+==============================================================================+
| How to organize the lit tests                                                |
+==============================================================================+

- If you write a test for matching a single DAG opcode or intrinsic, it should
  go in a file called {opcode_name,intrinsic_name}.ll (e.g. fadd.ll)

- If you write a test that matches several DAG opcodes and checks for a single
  ISA instruction, then that test should go in a file called {ISA_name}.ll (e.g.
  bfi_int.ll

- For all other tests, use your best judgement for organizing tests and naming
  the files.

+==============================================================================+
| Naming conventions                                                           |
+==============================================================================+

- Use dash '-' and not underscore '_' to separate words in file names, unless
  the file is named after a DAG opcode or ISA instruction that has an
  underscore '_' in its name.