[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