Addressed the rest of Florian's comments.

Addressed part of Florian's comments.

CFG before the patch, LCSSA broken:

In D68515#1872588, @jeroen.dobbelaere wrote:

Is the bitcast introduced by 'clang' (frontend), or was it introduced by one of the optimization passes ? In the latter case, which pass is this? We should probably handle it and
treat it as a 'gep with all-0 indices'... And make sure that the pointer-type for the llvm.noalias is somewhat usable.

If it is based on 'a pointer to int' conversion in the c-language, then it should be ok to just ignore it.

Jeroen, we discovered an assertion in introduceNoAliasWhenCopyGuardIndicesAreCompatible() for the case described below; we would appreciate your input.

@hiraditya Thank you very much for the code, I'm very interested in it. I'm trying to compile this and the 2/n revision together but I'm getting compilation failures, e.g.:

In D49994#1191386, @efriedma wrote:

I'd like an explanation for why the generated code is changing for AArch64... generating extra copies clearly seems like a downside. And there isn't any obvious reason for this change to impact register allocation: on AArch64, all i32 register classes contain exactly the same set of allocatable registers.

For some of the failing ARM/AArch64 tests, I see additional mov-s being performed; for example, in CodeGen/AArch64/and-sink.ll: if you take a look at the assembly after applying the patch, you will see an addtional mov for the trace when %c (w1) equals to zero. I'm not sure how important it is, so I would appreciate some feedback from ARM/AArch64 backend people. Please note that for performance-critical atomic compare-and-swap operations, performance is unchanged.

Differential is updated with:

All the test failures are mismatches between expected assembly and assembly produced. One exception is CodeGen/AMDGPU/early-if-convert.ll, where the backend fails with an assertion:

In D49994#1184441, @uweigand wrote:

The new code for f2 in cond-move-03.ll is in fact better, since it now actually uses the conditional move instruction instead of a branch ...

@jonpa Jonas, I see a different assembly in one of SystemZ unit tests; my memory of Z is pretty fuzzy, so could you please make sense of the change to see whether it is reasonable?

In D49994#1182189, @alexey.zhikhar wrote:

This patch fails 14 tests; however, it seems that the problem is not in the patch but in flaky test cases. I took a quick look at CodeGen/PowerPC/vsx.ll: the test case fails after not finding copy instructions, which were redundant and expectedly removed by this patch.

This patch fails 14 tests; however, it seems that the problem is not in the patch but in flaky test cases. I took a quick look at CodeGen/PowerPC/vsx.ll: the test case fails after not finding copy instructions, which were redundant and expectedly removed by this patch.

In D49994#1181808, @jonpa wrote:

Is this making sense, and what are your thoughts? What happens if you run your out-of-tree test cases with the SystemZ (-mcpu=z13) backend? Do you see any improvement? In that case, it seems like we have a test of real worth...

In D49994#1180443, @lebedev.ri wrote:

Probably needs tests. (Not that i know how to write one here)