Stanislav Mekhanoshin 92c1fd19ab Allow rematerialization of virtual reg uses
Currently isReallyTriviallyReMaterializableGeneric() implementation
prevents rematerialization on any virtual register use on the grounds
that is not a trivial rematerialization and that we do not want to
extend liveranges.

It appears that LRE logic does not attempt to extend a liverange of
a source register for rematerialization so that is not an issue.
That is checked in the LiveRangeEdit::allUsesAvailableAt().

The only non-trivial aspect of it is accounting for tied-defs which
normally represent a read-modify-write operation and not rematerializable.

The test for a tied-def situation already exists in the
/CodeGen/AMDGPU/remat-vop.mir,
test_no_remat_v_cvt_f32_i32_sdwa_dst_unused_preserve.

The change has affected ARM/Thumb, Mips, RISCV, and x86. For the targets
where I more or less understand the asm it seems to reduce spilling
(as expected) or be neutral. However, it needs a review by all targets'
specialists.

Differential Revision: https://reviews.llvm.org/D106408
2021-08-24 11:09:02 -07: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-07-25 14:05:08 +01: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
2020-06-15 16:18:05 -07:00
2021-02-17 16:01:32 -08:00
2020-06-15 16:18:05 -07:00
2021-01-21 10:51:36 -05: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
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-04-03 10:07:21 +01:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2020-08-09 20:50:30 +02:00
2021-03-15 21:44:15 +09: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.