Address comments.

LGTM

LGTM overall, one change that seems superfluous though.

Oh, I think now what do you mean: iterators stored in containers, thus iterators iterating over iterators. Yes, the current working of the checker does not support it because it stores iterator positions for both the prvalues and the glvalues. This is so from the beginning and this patch does not change anything about this behavior. Of course, this design concept is questionable, we can change it in the future. But not in this patch, this one is purely an NFC: it has exactly the same functionality as the previous versions, the only difference is that it does not hamper anymore with LazyCompoundVals but reaches the real region of the objects (and only in case of objects by value, I check the AST type for paramters), exactly as you requested.

In D88138#2294257, @aeubanks wrote:

I think I'm still missing how exactly this will fit into the pipeline. As in where is registerPassBuilderCallbacks() going to be called?

And a test like llvm/test/CodeGen/AMDGPU/opt-pipeline.ll for the new pass manager route would be nice to make sure this actually works.
something like RUN: opt -passes='default<O0>' -mtriple=... -disable-output -disable-verify -debug-pass-manager. Maybe checking all the normal passes isn't necessary like in the existing opt-pipeline.ll isn't necessary, just need to check that the custom passes (e.g. HexagonVectorLoopCarriedReusePass) are actually added.

Thanks for review! I will wait until next week.

Looks good. Makes the tsan and instrumentation interaction also cleaner.

Fix lock

In D88178#2293838, @nikic wrote:

In D88178#2293723, @lebedev.ri wrote:

Guess i'll just have to do it myself then.

I feel like I'm missing context here. Did I overlook review feedback somewhere?

In D88054#2292668, @thakis wrote:

All devs do incremental builds. Of course incremental builds should work.

I went ahead and fixed this in https://github.com/llvm/llvm-project/commit/0389eff4047a74bb1ba6c0603c9002b5c73b203e

Going forward, please don't leave stuff broken overnight.

Feel free to land when you have the -pie + compact unwind testcase.

Added diagnostic message

I think I'm still missing how exactly this will fit into the pipeline. As in where is registerPassBuilderCallbacks() going to be called?

comments added

Add HexagonVectorLoopCarriedReusePass using registerPassBuilderCallbacks

clang-tidy

I don't have commit access. What should I do?

In D87817#2294122, @junparser wrote:

In D87817#2291684, @lxfind wrote:

In D87817#2289365, @junparser wrote:

In D87817#2278816, @junparser wrote:

In D87817#2278717, @junparser wrote:

We try to find an general solution to handle some conservative & mismatch analysis in transformations caused by the change of cfg with coro.suspend intrinsic. However afaik, it seems quiet difficult to deal this without change framework fo coroutine.
This patch just fixes the known issue, it may happens in other passes, FYI.

one of the idea is that we do not generate default case for switch instruction of coro.suspend intrinsic. Instead, we find fall through coro.end for coro.suspend directly in corosplit pass. The only uncertain thing is whether fall through coro.end is moved by passes which may change the semantic.

@lxfind, what do you think about this idea?

Are you suggesting to not have an edge from the coro.suspend switch to the coro.end block? Would that make the coro.end BB a dead BB and could potentially get removed?

No, There is always path from entry to coro.end BB.

This is likely the right solution, but we do need to make it more general. In order for this to always work, I wonder if the proper place to insert this transformation is in LoopSimplify, which is a pass always executed before any Loop pass. That might guarantee that any loop pass will be able to handle this properly. I am not too familiar with loop passes, but maybe someone else could comment on that.

Loop exit-block insertion in LoopSimplify pass guarantees that all exit blocks from the loop only have predecessors from inside of the loop. It will break the dedicated form of exit blocks when we consider ignore coro.suspend path. Maybe there is other idea i haven't thought about.

This patch caused some failures (fullfp16-neg.s etc.) and seems changed the behavior of parsing "vmov.f16 s1,r2" for -fp16 from fail to pass. With this patch and -fp16, "vmov.f16 s1,r2" would be parsed to "vmov.16 s1,r2" which is defined to alias "vmov s1,r2".