This is an archive of the discontinued LLVM Phabricator instance.

[MachineCombiner] Use default latency model when no detailed model available
ClosedPublic

Authored by reames on Jan 4 2023, 4:01 PM.

Details

Summary

This change adjusts the cost modeling used when the target does not have a schedule model with individual instruction latencies. After this change, we use the default latency information available from TargetSchedule. The default latency information essentially ends up treating most instructions as latency 1, with a few "expensive" ones getting a higher cost.

Previously, we unconditionally applied the first legal pattern - without any consideration of profitability. As a result, this change both prevents some patterns being applied, and changes which patterns are exercised. (i.e. previously the first pattern was applied, afterwards, maybe the second one is because the first wasn't profitable.)

The motivation here is two fold.

First, this brings the default behavior in line with the behavior when -mcpu or -mtune is specified. This improves test coverage, and generally makes it less likely we will have bad surprises when providing more information to the compiler.

Second, this enables some reassociation for ILP by default. Despite being unconditionally enabled, the prior code tended to "reassociate" repeatedly through an entire chain and simply moving the first operand to the end. The result was still a serial chain, just a different one. With this change, one of the intermediate transforms is unprofitable and we end up with a partially flattened tree.

Note that the resulting code diffs show significant room for improvement in the basic algorithm. I am intentionally excluding those from this patch.

For the test diffs, I don't seen any concerning regressions. I took a fairly close look at the RISCV ones, but only skimmed the x86 (particularly vector x86) changes.

Diff Detail

Event Timeline

reames created this revision.Jan 4 2023, 4:01 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 4:01 PM
reames requested review of this revision.Jan 4 2023, 4:01 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 4 2023, 4:01 PM

the default latency information available from TargetSchedule.

Could you add some more wording here please?
Where does it come from?

reames added a comment.Jan 5 2023, 7:45 AM

the default latency information available from TargetSchedule.

Could you add some more wording here please?
Where does it come from?

TargetSchedModel::computeOperandLatency and computeInstrLatency, end up calling defaultDefLatency. That in turns end up returning 0 for transient instructions, MCSchedModel.LoadLatency for loads, MCSchedModel.HighLatency for "high latency defs", and 1 for everything else.

The TargeSchedModel is initialized from the MCSchedModule and the subtarget info. It mostly just pulls information from the MCSchedModel. The MCSchedModel is initialized (when no mcpu is defined) to a default initialized instance of the class (see GetDefaultSchedModel and MCSchedule.cpp Ln 25). The default values for LoadLatency and HighLatency are 4 and 10 respectively.

isHighLatencyDef defaults to false, and only x86 and AMDGPU override it. AMDGPU isn't interesting as it doesn't use MachineCombiner. X86 lists a set of divides, sqrts, scatter, and gather instructions.

asi-sc added a comment.Jan 9 2023, 1:57 AM

Previously, we unconditionally applied the first legal pattern - without any consideration of profitability

Thanks for addressing this issue for default scheduling models! I also faced it some time ago, but I didn't have time to take a closer look.

LGTM (I don't check all x86 tests)

This revision was not accepted when it landed; it landed in state Needs Review.Jan 20 2023, 9:28 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.