<div dir="ltr">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.<div>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. </div><div><br></div><div>This patch is conversative and won't change any current optimization behavior. </div><div><br></div><div>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. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 2, 2022 at 10:49 AM Nikita Popov via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">nikic added a comment.<br>
<br>
`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.)<br>
<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D128999/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D128999/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D128999" rel="noreferrer" target="_blank">https://reviews.llvm.org/D128999</a><br>
<br>
</blockquote></div>