[PATCH] D75918: [MachinePipeliner] Refine the RecMII calculation

[Brendon Cahoon via Phabricator via llvm-commits]

bcahoon added a comment.

In D75918#1916326 <https://reviews.llvm.org/D75918#1916326>, @lsaba wrote:

> In D75918#1916156 <https://reviews.llvm.org/D75918#1916156>, @bcahoon wrote:
>
> > Hi @lsaba - this fix looks good to me. Thanks! It will be challenging to create a test case on Hexagon due to the output dependences. How to do get so many output dependences on your target?
>
>
> re
>  Thanks for the fast reply!
>  we have an implicit physical register that certain instructions define, thus having several instructions in the code would create these output chains, the most similar to this that I found in Hexagon was the usr_ovf register, but I also saw that the Output Deps for these registers get removed in HexagonSubtarget::UsrOverflowMutation::apply.
>
> (In powerPC there's a carry register, but the Output latency is 0)
>
> I think stores to physical registers would also create such output chains?
>
> This calculation could also happen with Data dependencies if there is more than one def,use chain between two instructions (for example multiple output instructions), are those present in Hexagon?


Yep, stores to physical registers will create output dependences, which can be done using inline assembly. At least, most of the code in the pipeliner that deals with output dependences is exercised using inline asm code.

The only Hexagon instructions with two outputs that the compiler generates are the post-increment load instructions, and it would be difficult to create a chain of these. There are some esoteric instructions, but they are typically generated through intrinsics only.  I can try to create a test for this...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75918