Also update foldAndOfICmps to handle not equal (U)INT_MIN/MAX

Fix copy/paste mistake in comment

Rebase after making one of the tests better

Rebase with the tests pre-commited

Disable the 64-bit load+store optimization for vectors types. Type legalization will deal with this.

Rebase

In D63638#1581973, @chandlerc wrote:

Just to make sure we're on the same page (and sorry I didn't jump in sooner)...

With the old PM, *anything* that is always_inline *gets* instsimplify run on it, even at -O0, even if you didn't want that. So using -instsimplify explicitly is, IMO, not any more scary of a reliance on LLVM's behavior than the old PM already subjected us to...

That said, if the x86 maintainers are comfortable with *only* using the new PM (because it has an always inliner that literally does nothing else and thus has an absolute minimum amount of LLVM transformations applied), I certainly don't have any objections. =D

Are the multiply test changes due to the flags being used by seto? But seto usage should never be in danger of creating the instruction duplication we're seeing in the motivating case. It does look like we're getting an improvement on those tests, but not for the reason we're selecting LEA.

Switch to returning undef

LGTM

In D64285#1583589, @xbolva00 wrote:

if (Bitwidth == 0) {

  IC->dump();
}

%cmp.i = icmp ne %struct.LIST_HELP* %List.addr.0, null

getScalarSizeInBits probably returns 0 for pointers. Only DataLayout knows pointer size.

Rebase after commiting tests

Are we really allowed to change the exact flag from InstSimplify?

Move the allowsMemoryAccess call into isLoadBitCastBeneficial

What if we just only check the output from the new pass manager. I don't think I care about the differences between the two.

In D63638#1574740, @leonardchan wrote:

In D63638#1574373, @craig.topper wrote:

There's some inliner running because the intrinsics are implemented as always_inline functions and they are clearly being inlined in -O0. In a previous post, Chandler said the new PM has a special inliner for always_inline in -O0 and the old pass manager just used the normal inliner.

Oh I forgot that these were marked always_inline. Yes, this special inliner is the AlwaysInliner which is purposefully designed differently than the normal inliner in the legacy PM according to D23299. I'm proposing that we could perhaps just edit the tests to ignore the bitcasts since the different behavior is intended (the AlwaysInliner isn't doing extra work like combining these bitcasts). This way we can still check for the various intrinsics emitted without their IR instruction mappings getting optimized out, and we won't need to use instsimplify to make sure the IR matches.

Taking an example from my other patch, we'd have something like:

diff --git a/clang/test/CodeGen/avx512f-builtins.c b/clang/test/CodeGen/avx512f-builtins.c
index 15571b639b6..4ad63d73235 100644
--- a/clang/test/CodeGen/avx512f-builtins.c
+++ b/clang/test/CodeGen/avx512f-builtins.c
@@ -10479,7 +10479,7 @@ __m512i test_mm512_maskz_abs_epi64 (__mmask8 __U, __m512i __A)
   // CHECK: [[SUB:%.*]] = sub <8 x i64> zeroinitializer, [[A:%.*]]
   // CHECK: [[CMP:%.*]] = icmp sgt <8 x i64> [[A]], zeroinitializer
   // CHECK: [[SEL:%.*]] = select <8 x i1> [[CMP]], <8 x i64> [[A]], <8 x i64> [[SUB]]
-  // CHECK: select <8 x i1> %{{.*}}, <8 x i64> [[SEL]], <8 x i64> %{{.*}}
+  // CHECK: select <8 x i1> %{{.*}}, <8 x i64> {{.*}}, <8 x i64> %{{.*}}  // Ignore the output of the redundant bitcasts
   return _mm512_maskz_abs_epi64 (__U,__A);
 }

It also seems like for some of these tests that some bitcasts are already ignored.

There's some inliner running because the intrinsics are implemented as always_inline functions and they are clearly being inlined in -O0. In a previous post, Chandler said the new PM has a special inliner for always_inline in -O0 and the old pass manager just used the normal inliner.

What is one of the shifts has the "exact" flag set and the other doesn't?

-Rebase
-Add a hack to the reduction cost model code that keeps v2i32, v4i16, v2i16 from having the same cost as v4i32 and v8i16 due to the type legalization cost.