[PATCH] D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations.

Mingming Liu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 7 10:52:20 PST 2021


luna added a comment.

In D114832#3176957 <https://reviews.llvm.org/D114832#3176957>, @lebedev.ri wrote:

> Can the issues instead be viewed as missed transformations that should be implemented instead of trying to prevent creating those "bad" patterns?

For my understanding of 'missed transformations', would this transformation takes the IR after SROA pass (pasted in https://gist.github.com/minglotus-6/cae98ad58f7ae6cac8dd848e75c2bde9) as input,
doing something like instruction combine or clean ups, with the desired output the same as this patch did in the SROA pass?

I have also thought of the approach of a separate transformation in the beginning, but decided to implement this first (easier to prevent split in the first place than analyzing results after split and combine them together)

Now upon this suggestion, I think it twice about how to do it in another pass (maybe right after SROA); some thoughts:

1. The basic essence of the current patch is to analyze the use pattern of an allocation, and the use pattern information (offsets of fields) is still in the IR after SROA pass. From this perspective it might be possible to do it in a separate pass.
2. However, a pattern matcher (to analyze offsets after split) might be fragile, and won't continue to work if the specific instructions in IR changes (but the semantics of constant stores remains).

I'm wondering if there happens to be an example of existing passes that might be inspiring for a use case of joining instructions like this. Also would like to hear concerns of the current approach so maybe I can iterate from there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114832



More information about the llvm-commits mailing list