[PATCH] D106312: [AMDGPU] Allow rematerialization of virtual reg uses

Stanislav Mekhanoshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 19 14:10:17 PDT 2021


rampitec created this revision.
rampitec added a reviewer: arsenm.
Herald added subscribers: foad, kerbowa, hiraditya, t-tye, tpr, dstuttard, yaxunl, nhaehnle, jvesely, kzhuravl.
rampitec requested review of this revision.
Herald added a subscriber: wdng.
Herald added a project: LLVM.

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 on top of what we are already
checking for VOP (e.g. implicit uses/defs) and which is already working
with our SIInstrInfo::isReallyTriviallyReMaterializable() is accounting
for tied-defs which normally represent a read-modify-write operation
and not rematerializable. Everything else is proven to work by the
existing VOP implementation. We already allow such uses and bypassing
the rest of generic checks for VOP, but cannot rematerialize SOP
instructions with register uses.

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

Applying the same logic to other targets shows that there are really
non-trivial situations with uses so the logic is not generally
acceptable for any target.


https://reviews.llvm.org/D106312

Files:
  llvm/lib/Target/AMDGPU/SIInstrInfo.cpp
  llvm/test/CodeGen/AMDGPU/remat-sop.mir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D106312.359910.patch
Type: text/x-patch
Size: 4820 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210719/ecfae7ba/attachment.bin>


More information about the llvm-commits mailing list