[PATCH] D128999: [CGSCC] Don't count calls to intrinsic functions in finding potential deviritualizations.

[Rong Xu via llvm-commits]

Yes. Thanks for clarifying these steps. These actually were what I meant: a
memcpy libcall was devirtualized and replaced with llvm.memcpy intrinsic.
The code I changed in ScanSCC which will perform after the devirtulization
so whether to count matters here.
If we filter all the intrinsics, in some cases, we will not do another
round of CGSCC. I agree with you that we probably don't need it as inline
will not happen. But I need to point out that there are other IPA
optimizations that also happen here -- like propagation  of attributes and
some cleanup.

This patch is conversative and won't change any current
optimization behavior.

If you think we should take a more aggressive approach that filters all the
instricisc, I'm all for it too as long as people accept the behavior
change.

On Sat, Jul 2, 2022 at 10:49 AM Nikita Popov via Phabricator <
reviews at reviews.llvm.org> wrote:

> nikic added a comment.
>
> `memcpy` the libcall can be an indirect call target. `llvm.memcpy` the
> intrinsic cannot be. If an indirect `memcpy` becomes direct and is then
> replaced with the intrinsic, that's a divirtualization, but I don't think
> it's one relevant for the purposes of DevirtSCC, because such a call cannot
> be inlined. (Phrased like that, I think the relevant property here is not
> so much that something is an intrinsic, but that it is a declaration, as
> declarations are not eligible for inlining.)
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D128999/new/
>
> https://reviews.llvm.org/D128999
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220706/9abef0dc/attachment.html>