[PATCH] D70066: [MacroFusion] Limit the max fused number as 2 to reduce the dependency

qshanz via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Nov 24 18:44:42 PST 2019


steven.zhang added a comment.

In D70066#1756949 <https://reviews.llvm.org/D70066#1756949>, @fhahn wrote:

> I am not sure if this example best illustrates the issue. Is your main concern here potentially longer dependency chains?


My main concern is that, some node (such as Node A in my below example) lose some freedom to do the schedule. We are creating unnecessary dependencies for it. Things become more worse if

  ADD
  ADD
  // expected some instructions could be scheduled here.
  ADD
  ADD

Current implementation will force all these 4 ADD scheduled together and no instructions is allowed to insert in-between {ADD,ADD} {ADD,ADD}

> The original test case explicitly checks the 2 fused pairs and without knowing details about the micro architecture, there is no way of telling if it is beneficial to schedule `add; add; sub` adjacent. The reason 2 pairs are created is because for `fuse-arith-logic` patterns, the opcode of the first MI can also match the second MI. I think fuse-arith-logic is the only fusion pattern on AARch64 that has this property. And only the ExynosM4 has it enabled. I think @evandro originally added those patterns, maybe he can shed some light on the benefits?

Yeah, my point is that, as you said, we didn't see the benefit to schedule `add;add;sub` adjacent from micro architecture aspect, but we see the bad things happens as I gave below.

> Alternatively, are there similar cases for other targets?

No, as far as I know currently. But no guarantee for the future, as hw is moving forward you know.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70066/new/

https://reviews.llvm.org/D70066





More information about the llvm-commits mailing list