Yikes! Thanks for the revert. I didn't see the email from the bot until just about 2 minutes before you reverted. I'll see if I can reproduce.

Msan complains about this patch https://lab.llvm.org/buildbot/#/builders/74/builds/11664/steps/17/logs/stdio

It fails as is https://lab.llvm.org/buildbot/#/builders/169/builds/8994/steps/30/logs/stdio

I will commit/revert it myself.

In D128729#3615964, @MatzeB wrote:

In D128729#3615885, @vitalybuka wrote:

Do we need a test for llvm-link?

I guess. So much trouble to keep these strange build scripts working...

Do we need a test for llvm-link?

restore blank line

exactly as reverted revision
886715af962de2c92fac4bd37104450345711e4a + 572b08790a69f955ae0cbb1b4a7d4a215f15dad9

Reverted with cdfa15da94f06289dcf86173d18b6627f92ac403 (inlcuding 572b08790a69f955ae0cbb1b4a7d4a215f15dad9)

This bot is broken by this patch
https://lab.llvm.org/buildbot/#/builders/85/builds/8881

Maybe then just keep as is to avoid new preprocessor branches?

The rest is LGTM

Could you please move refactoring (like extraction emitPrologue) into a separate CL?

In D114487#3593011, @fhahn wrote:

In D114487#3555041, @vitalybuka wrote:

@fhahn
This is reduced reproducer:

Thanks! I think I was able to isolate the bits that caused problems:

1. Unecessarily looking through selects outside the loop
2. Introducing branches on undef/poison when looking through selects.

I recommitted the change in e9cced27390ba38eac1144aa1240281a1edadec0. I couldn't test with msan though, as it's not available on macOS. Please let me know if you see further issues.

Thanks for the fix!

https://lab.llvm.org/buildbot/#/builders/105/builds/26496
and
https://lab.llvm.org/buildbot/#/builders/19/builds/11181

maybe #define _GNU_SOURCE as in documentation?

I believe "Depends on" should be in the summary, no in the title

No need to recover my snapshot, I'll just comment here.

In D126929#3567491, @hctim wrote:

Update.

In D127163#3564919, @hctim wrote:

We already have -fsanitize=memtag that implies -fsanitize=memtag-heap and -fsanitize=memtag-stack.

It makes the most sense IMHO in the world where we want heap MTE. -fsanitize=memtag-heap is the most reasonable instead of -fsanitize-memtag-heap, as "do i need -fsanitize=memtag as well, like MSan?" is never a question.

Up to you if you, if you want to wait for Peter. Feel free to remove and land it if you think it's done.
I added blocker only to make sure that review is shown to @phosek on Phabricator main page.

Why do we want this as a separate -fsanitize=
Maybe better to have some modifier flag like -fsanitize-memtag-globals=1 ?

I simplified this a little bit, but I guess this is effectively the same.

rebase

fix rebase

rebase

yes, however I have no idea if we need !TC.getTriple().isOSFreeBSD() !TC.getTriple().isOSNetBSD() !TC.getTriple().isOSOpenBSD()) etc.
I guess if make mistake it will be noticed and fixed.

In D86669#3561225, @efriedma wrote:

In D86669#3561125, @vitalybuka wrote:

In D86669#3560983, @efriedma wrote:

If you're seeing a miscompile, something is probably wrong with the caller. getUnderlyingObjects() is, in general, not guaranteed to produce an identifiable object. If the caller cares, it should check; for example, GlobalsAAResult::getModRefInfoForArgument checks all_of(Objects, isIdentifiedObject).

I am not sure why do don't want to make it guaranty with a patch like this?

How could we possibly guarantee that? In general, we're going to find some opaque thing that both getUnderlyingObjects() and its caller can't understand.

I mean, I guess we could define an API that narrowly guarantees it looks though all bitcast, addrspacecast, gep, phi, and select operations. But that would be expensive in general, and it's not obvious to me it solves anything.

In D86669#3560983, @efriedma wrote:

If you're seeing a miscompile, something is probably wrong with the caller. getUnderlyingObjects() is, in general, not guaranteed to produce an identifiable object. If the caller cares, it should check; for example, GlobalsAAResult::getModRefInfoForArgument checks all_of(Objects, isIdentifiedObject).

Thanks.
LGTM with few nits

LGTM, with Asm test and bitcode stuff moved as explained.