This is an archive of the discontinued LLVM Phabricator instance.

[TII] NFCI: Simplify the interface for isTriviallyReMaterializable
ClosedPublic

Authored by sdesmalen on Jul 28 2023, 3:59 AM.

Details

Summary

Currently isTriviallyReMaterializable calls
isReallyTriviallyReMaterializable and
isReallyTriviallyReMaterializableGeneric. The two interfaces
are confusing, but there are also some real issues with this.

The documentation of this function (see below) suggests that
isReallyTriviallyRematerializable allows the target to override the
default behaviour.

/// For instructions with opcodes for which the M_REMATERIALIZABLE flag is
/// set, this hook lets the target specify whether the instruction is actually
/// trivially rematerializable, taking into consideration its operands.

It however implements something different. The default behaviour
is the analysis done in isReallyTriviallyReMaterializableGeneric,
which is testing if it is safe to rematerialize the MachineInstr.

The result of isReallyTriviallyReMaterializable is only considered if
isReallyTriviallyReMaterializableGeneric returns false. That means
there is no way to override the default behaviour if
isReallyTriviallyReMaterializableGeneric returns true (i.e. it is safe to
rematerialize, but we'd rather not).

By making this a single interface, we can override the interface to do either.

Diff Detail

Event Timeline

sdesmalen created this revision.Jul 28 2023, 3:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 28 2023, 3:59 AM
Herald added subscribers: pmatos, asb, foad and 9 others. · View Herald Transcript
sdesmalen requested review of this revision.Jul 28 2023, 3:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 28 2023, 3:59 AM

This interface never made any sense

This interface never made any sense

Agreed. I still find the need for isReallyTriviallyReMaterializable() a bit confusing, over simply having only isTriviallyReMaterializable(), but I didn't want to complicate this patch too much. It is possible to remove this layer, but that does complicate the overriden Target methods a bit more.

dexonsmith resigned from this revision.Jul 28 2023, 5:43 AM
piotr added a comment.Jul 28 2023, 6:52 AM

Thanks, AMD changes LGTM. I spotted this weirdness recently when staring at some remat code for AMDGPU. (It's not a serious issue for us, because the generic check is really conservative for our target, and we typically do not want to block the remat when the generic check returns true).

llvm/include/llvm/MC/MCInstrDesc.h
522–523

"method is" or "methods are"

llvm/lib/Target/X86/X86InstrInfo.cpp
877

Doesn't it need the conditional change as in line 898 below?

sdesmalen updated this revision to Diff 545157.Jul 28 2023, 7:26 AM

Addressed comments

llvm/lib/Target/X86/X86InstrInfo.cpp
877

Good spot, thank you!

sdesmalen marked 2 inline comments as done.Jul 28 2023, 7:29 AM
This revision is now accepted and ready to land.Aug 4 2023, 10:08 PM
nemanjai accepted this revision.Aug 6 2023, 3:55 AM

Seems fine to me - certainly from a PPC perspective.

This revision was landed with ongoing or failed builds.Aug 7 2023, 6:01 AM
This revision was automatically updated to reflect the committed changes.