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

[David Li via Phabricator via llvm-commits]

davidxl added a comment.

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

> In D114832#3177534 <https://reviews.llvm.org/D114832#3177534>, @davidxl wrote:
>
>> The bad code pattern generated is probably not general enough to be useful to introduce a cleanup pass or to enhance existing pass to do so -- it will probably just shift the complexity from one pass to another. Fixing this at the source (SROA) is reasonable (unlike other canonicalization pass, this code pattern from SROA actually makes IR much worse)
>
> Who defines what is/isn't reasonable? :)
>
> As i see it, the input IR may or may not already have such bad patterns that are similar to the bad patterns you are trying to avoid producing here.
> Trying to avoid producing it has compile time cost: https://llvm-compile-time-tracker.com/compare.php?from=0850655da69a700b7def4fe8d9a44d1c8d55877c&to=8a4304c8f4253fb1944e5e5988a24285a14181c4&stat=instructions
> So, you've paid for avoiding producing more bad patterns, but you are still left with the ones that were already there.
>
> Alternatively, instead of paying for trying not to introduce bad patterns, you could pay for trying to improve all of the patterns afterwards, regardless of their source.
> Then, you still end up paying, but end up with not just the SROA patterns improved.
>
> This is a very standard logic behind IR changes - if something doesn't understand the pattern, generally don't try to workaround it elsewhere, just fix the missing piece.

I agree with most of what you said  as a general principle, while analysis should be done case by case :)

The assumption is that the producer (SROA) is pretty much the only creator of the pattern (excluding manually written IR), thus cleaning it up downstream does not really help in sharing. The compile time cost is also shifted. Imagine another hypothetical scenario: if we there are N different unique bad patterns that can be handled by one single analysis pass in the source pass, we may need to have N different downstream pass changes to handle them resulting in more waste.

Having said that, suggestions on which downstream pass to handle this is useful. IIRC Mingming considered CodegenPrepare where some taildup can be done to handle tailcalls ...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114832