[llvm] [MemCpyOpt] Continue merging memset with unrelated clobber (PR #89550)

[Nikita Popov via llvm-commits]

nikic wrote:

> > [](https://llvm-compile-time-tracker.com/compare.php?from=ba702aa067c0659d2263d2144d38666efa4a1750&to=965d72d4a9918e00a02609c40f31d00d8fe63d64&stat=instructions:u)
> 
> The stage1 impact looks obvious. If you are not happy with the compile-time, I will try to avoid revisiting the ones to the same object in this patch. I have a basic idea in mind to process one basic block in one pass now:
> 
>     * maintain a map, whose key is the underlying object, and the value is corresponding MemsetRanges
> 
>     * traverse the instructions one by one
> 
>     * once a clobber appears
>       
>       * for a store/memset, if the map contains the corresponding underlying object, try to insert it into the MemsetRanges. Otherwise, we flush all may-aliased MemsetRanges, and insert a new MemsetRanges into the map.
>
>       * for other clobbers, we flush the aliased ranges in the map, this requires checking every MemsetRanges in the map.
> 
> 
> This method avoids revisiting the ones to the same object and the ones don't read or write memory. But anyway, for a long non-aliased store sequence, it's still quadratic.

Your plan sounds generally reasonable to me. Some notes:

 * Just because the underlying object is different, doesn't mean that they don't alias. This is only true to identified objects. So when inserting a new underlying object into the map, we should check aliasing against other underlying objects already in the map, and flush them if necessary.
 * With your implementation, we could always limit the total number of underlying objects in the map, so if it exists some number N we can flush out an entry before adding a new one. That will make sure we never get (problematic) quadratic behavior.



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