[PATCH] D89447: [MachineInstr] Add support for instructions with multiple memory operands.

[Michael Liao via Phabricator via llvm-commits]

hliao added a comment.

In D89447#2331842 <https://reviews.llvm.org/D89447#2331842>, @Kayjukh wrote:

> This looks like the same as my old patch (https://reviews.llvm.org/D80161). There are additional details available on the commit's Phab page <https://reviews.llvm.org/rG7019cea26dfef5882c96f278c32d0f9c49a5e516>. To put it in a nutshell, some codes can trigger a very large amount of calls to the aliasing check (see the repro provided by @nemanjai: https://pastebin.com/tRtTQdSa), which results in a very large increase in compilation time.
>
> Bounding the number of checks may be a good solution, even though it would be nicer to have something more clever that could allow all the operands to be checked. Not sure how feasible this would be though.

Yeah, I could reproduce that compile-time issue. That issue happens in the post-RA scheduler. I didn't find that as the generic x86 backend disables the post-RA scheduler.
Back to the compilation issue itself, as a short-term solution, putting a limit seems reasonable to me as most native machine instructions probably only take 2~3 memory operands. We may also add a target hook to get that more reasonable for the underlying target. If any instruction has more memory operands that that limit, we just take them conservatively. In long run, adding alias result caching in basic-aa would reduce time but increase space required.

A relevant question is that do we need to run full AA in the post-RA scheduler if the pre-RA scheduler is already enabled. Except for the newly generated memory operations (spill, reload, rematerialized loads, and etc.), we only got registers allocated and assigned in RA. The memory dependency after the pre-RA scheduler still holds. Running AA check on these memory instructions only reproduce the same result. For register spills/reloads, they won't alias to these existing memory instructions but only alias to their counterparts. They also don't have too much space to be scheduled around due to the register dependency. By pruning these unnecessary memory dependency setup, we could save lots of compilation time contributed from the post-RA scheduler.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89447