IIUC, the additional set would be used for the non-alloca cases, as we have to ensure that there are overwrites along all paths to the exit.

For a more direct comparison, I offer https://godbolt.org/z/fqAhUC . The lack of optimization in the later case is because we're forced to mark the call to __builtin_memcpy in the inline memcpy as nobuiltin. If we instead rename things, this issue doesn't happen: https://godbolt.org/z/FKNTWo.

I think there are 2 cases to distinguish:

1. For accesses to non-alloca objects, this matches what the intrinsic achieves I think. We can only eliminate stores to objects that are visible after the function returns, if they are overwritten along all paths to the exit. So if we have determined a set of blocks that overwrite A (and there are no reads in between), we could check if all paths to the exit from A must go through one of the overwriting blocks. I think that matches your suggestion.

Thanks for working on this!

(I really need to circle back and finish the LocationSize migration...)

Please wait for a stamp from another reviewer here, too.

LGTM modulo a few cosmetic nits. Similar to the previous review, please wait for approval from someone with more ownership here before landing.

Thanks so much for working on this!

Ack -- I'll do that in the future.

thanks for this!

I see -- that seems like a much broader change, but also probably worthwhile. I have a few ideas about how to tackle that; let me see what I can come up with locally.

Friendly ping Gerolf (or anyone else who has opinions on standardish benchmarks) :)

I have concerns on so much plumbing changes to make the small heuristic change.

ping :)

Thanks for the review!

Oof, yeah, these look similar, but it's not clear to me if there's a good way to unify them as a part of this patch (or lift this out to there). Lemme poke it a bit and see :)

Updated to plumb through the "are we doing ThinLTO || prelink LTO" bit in a way that makes sense to me. Suggestions for potentially better approaches is welcome :)

Yup - I also don't know of any location caching the cost. I wonder if this was a nerver-realized goal, and whether it is abandoned. May be worth checking with the author of the comment?

Looks like this was done in https://reviews.llvm.org/D65280; closing

On the first bullet, I'm trying to find where InlineCost values are cached. Are we doing that?

Until recently, both CrOS and Android disabled FORTIFY wholesale when any of asan/msan/tsan were active. Bionic recently got support for FORTIFY playing nicely with sanitizers, but that support boils down to "turn off all the FORTIFY runtime checks, but leave the ones that generate compiler diags on."

LGTM after this last nit is addressed. Like said, I plan to leave the final stamp to someone with more context. Thanks again!

Thanks for this! I'm always happy to see reduction tooling gain new powers :)

So there are existing test with 0 sized objects that would fail if we do not have the Size != 0 check but I'll add a few more to nail down what we expect as soon as I find the time. It might take a week or two though.

Thanks for this!

(It's interesting to me if gcc doesn't warn about that libcxx code, since the whole point of the gnuc 5.0 check there was "the compiler should check this for us now"...)

Just a few more nits, and this LGTM. Thanks again!

Should we also have a quick test-case in Sema/ verifying that we still get the warnings that Eli mentioned?

Thanks for looking into this!

Thanks for reviewing!

I don't immediately see any issues with this patch, but it's outside of my area of expertise, so I'll defer to the other reviewers :)

Thanks!

Thanks for this!

Does this have any significant impact on -fsyntax-only performance?

Addressed feedback

Thanks!

LGTM, since this is a workaround to keep things rolling while we work on a more general fix.

thanks!

Thanks!

Apologies for the latency of my updates.

Chatted with Eli offline; updated here to reflect the conclusions of that.

thanks for this!

Thanks for this!

thanks!

(Now that we have D67307, is this still needed? Happy to review if so, but this seems to be addressing primarily debuginfo-related bits)

Thanks for this!

Thanks!

Assuming the test in D66495 (in part) covers this, LGTM with an optional nit.

lgtm with a few nits. Thanks!

Thanks!

Thanks!

Thanks for this! Two nits and a question

Thanks for this!

Thanks for this!

SGTM. Thanks for the review!

Thanks! If it's easy to come up with a small regression test (like David mentioned on the bug, reverse_iteration may be a great help), please do so and commit it with this. Otherwise, LGTM as-is.

LGTM with one change -- thanks!

thanks for this!

just a few drive-by nits/comments from me. as usual, not super familiar with clang-tidy, so i won't be able to stamp this.

LGTM

Thanks for this!

Thanks!

Thanks!

Thanks!

just two stylistic nits; lgtm afterward. thanks for this!

Thanks!