Sorry for leaving this open for so long; various distractions kept popping up -- I'll wait a day to give a last chance for any objections and land tomorrow.

I think we do need to settle the question of whether "new" also needs to call this fence... if it does, we need to measure the compile-time/performance impact on existing code, and if it doesn't, we'll likely end up with two overlapping solutions for very similar issues.

Just return void instead of an opaque pointer, take a size argument, drop early CodeGenPrepare lowering.

I *didn't* change ObjCARCAliasAnalysis, but left a TODO. I don't have any good way to evaluate a "real" fix (i.e. doing the recursive queries in the modern way), and having the intent only documented in years-old revision history feels hard to spot. Not really a strong opinion though, happy to do something more intrusive there.

I'm also happy to just strengthen this to a pointer-specific fence (that returns void), that acts otherwise just like asm volatile("" : : "r"(ptr) : "memory") if that would make this more palatable. The only optimization I have in mind for the pointer-returning version is something to allow folding "store/fence/load" to a bitcast, which I don't think is important enough to be worth spending a lot of time on.

Rewrite the LangRef entry. This makes the operation of the fence clearer (it doesn't really change the behavior of TBAA at all; instead it just prevents any other optimization pass from being able to make use of TBAA for the given pointer).

This doesn't necessitate any changes to TBAA (i.e. it doesn't have to try to identify the "source" of a pointer to know if it comes from a fence or not). Instead, what prevents incorrect behavior is that, since llvm.tbaa.fence's memory effects are opaque (well, aside from being ArgMemOnly), the subsequent operation can't be reordered or eliminated. In this case, TBAA will still report NoAlias if asked about the two operations; but that result doesn't matter because you can't optimize based on that fact with a fence in between them (since the fence could, as far as the optimizer is concerned, do arbitrary loads and stores to the region of memory).

Added a LangRef entry that I hope clarifies things.

Add LangRef entry.

Adding @zygoloid as a p2590 author for review

Rebase

Would you mind committing for me? I don't have commit access.

Nits.

Use utils/update_cc_test_checks.py for the codegen test.

Unconditionally do fold, use replaceUse, remove unnecessary pipe redirection.

In addition to the release notes addition, I also added an entry in LanguageExtensions.rst.

Per comments.

Summarizing a brief offline discussion: I think it's probably fine to just get rid of the SemaChecking changes entirely; type-checking here is done by the generalized builtin-handling code. I'll do the change if there's no objection.

Rebase, futz with parent diffs in arc for wenlei@.

Fix langref nit, use update_test_checks.py.

Rebase

Movie logic into BasicAA.

Clean up nit.

Abandoning in favor of merging this functionality into BasicAA in D136514, as suggested in the review there.

Fix the LangRef changes -- left some junk lying around.

Thanks, think I caught everything this time around.

Per review comments.

Per review comments.

Per review comments.

Per review comments.

ping @nikic, would you mind taking another look? I think with the changes you suggested this ends up as a much cleaner stack (being able to avoid duplicating so much of the assume handling really cuts down). My followup plan is to expand this to handle the possibility of inline storage (e.g. the small string optimization), which is where we incur more of the costs, but I'd rather build on something stable before going much further.

Fix out-of-date comment.

Add langref change for separate_storage attribute.

Fix build.

Fix build, move out-of-date comment.

Update per review comments.

Rather than adding a separate aliasAt() API, we should add an extra optional argument to alias(). Especially when it comes to the Concept/Model/Base I don't see a value in having both alias() and aliasAt().

Removing from draft to get some feedback, but still more or less an RFC at the moment.

(For background: I'm a jemalloc maintainer and wrote N2293).

Ah, gotcha, thanks. Still learning the LLVM diff workflows.

Add (a / y) * y % y tests, make Opcode first arg, add Alive2 links to the commit message.

BTW, re-reading I realized I phrased that diff update poorly. I meant to say something more like "now that I understand better, it's obvious to me that you're right", not like "that thing you pointed out was obvious"; hopefully it parsed that way, and sorry if it didn't.

Merge cases into simplifyDivRem

In D102864#2773521, @spatel wrote:

No problem. I can commit on your behalf. To confirm - use your gmail address for author info?

I don't have commit access. Happy to split this in two and do two diffs if you'd prefer, though.

Add commuted and vector test cases.