[llvm] [MCP] Move dependencies if they block copy propagation (PR #105562)

Gábor Spaits via llvm-commits llvm-commits at lists.llvm.org
Sun Aug 25 10:07:29 PDT 2024


spaits wrote:

> I'm still concerned about introducing rescheduling instructions in MCP. Is there possibility we enhance pre-RA machine scheduler to achieve the same effect?
> For example, changes in `llvm/test/CodeGen/AArch64/GlobalISel/arm64-atomic.ll` can be also achived by disabling pre-RA machine scheduling, i.e., `-enable-misched=0`.

I don't really think the logic of this would fit into the current scheduling mechanism.

- The scheduler operates on a scheduler region level, not on a basic block level. As far as I know, the scheduler regions are smaller than a basic block.

- This could be worked around. But the result would be less good, since the copz propagations would happen on smaller scope.

- We couldn't really integrate the stuff into the secheduler. What we would have is this:
--  Modify backward propagation, so it doesnt actually propagate, but just gives back potentional propagations.
-- Then call the existing logic for `moveInstructionsOutOfTheWayIfWeCan` (I promise I will find a better name for it :) ).
-- All this would happen after scheduling. So basically it would work the same, but at a different place.


In conclusion just the current stuff would be moved, we would have less code reuse.


So I think this logic is a bit incompatible with the scheduler. The only thing that is  common between them is the use of a Dependency graph.

Or maybe I could take a whole different approach:
- Do a copy prop, save the potential copy propagations.
- When scheduling take these into acoount somehow.

This would be less general I think, because if a dependency blocks some copies that is not caused by the scheduler it may would not be recognized and moved.

https://github.com/llvm/llvm-project/pull/105562


More information about the llvm-commits mailing list