Ping. I don't see any comments that require action on my side.

In D72740#1822003, @RKSimon wrote:

This (and D72739) should be in 10.0 - please can you raise a bug and block https://bugs.llvm.org/show_bug.cgi?id=44555

Remove target datalayout string from the test

Pass tripple/target-cpu via opt's --triple/--mcpu options

Probably not too much important because should be handled by the vector predicated instructions/intrinsics, but still

Thanks for working on this! I'm really interested in using this functionality so here are some comments on the main interface header.

• Address Erich's comment + clang-format.

to change this logic if there is a consensus on how inlining should be handled in case of "null-pointer-isvalid" attribute mismatches.

Note that, I am expecting that functions with alwaysinline attribute should still get inlined. If that happens and caller does not have this attribute, then optimizer is free to remove the checks.

The test passes without that "-O2" but I'm not sure why it was there originally...

Improve some comments.

In D42717#1007875, @brzycki wrote:

@a.elovikov and @dberlin does this look good to commit?

I might be missing something, but why don't we enable DT back in LVI after the JT pass finishes and flushes the DDT? Is it possible that we end up with disabled DT *after* the JT?

I've just submitted https://llvm.org/PR36133 containing a testcase that show how JumpThreadings miscompiles (without crashes) the code due to DomTree not being updated between the iterations of JumpThreading itself.

Use regsOverlap instead of isSuperOrSubRegisterEq.

Indeed, on X86 checkRegistersAlias is just isSuperOrSubRegisterEq (although the former would be the right choice if that was not so :)).
Comment was added - thanks for the exact text!

• Move TODO from the test to the actual code.

In D41913#973706, @mssimpso wrote:

Also, this should be a release blocker if it's not already. Thanks!

In D40524#951832, @andrew.w.kaylor wrote:
I'm not terribly familiar with MIR as it appears in a test like this, but I can't see any reason that your proposed testcase would be invalid. I do think it's extremely unlikely to arise in actual generated Machine IR, since we hardly ever use the 8-bit high registers. What I'd like to do is commit the change from this review as is, and file a new Bugzilla report to track the 8bit_hi issue. Does that sound reasonable to you?

I'm not sure if the following is possible/legal but it fails even with this patch:

There is a typo in the summary: "were are", "make award".

• Address review comments.

Ping.

Rebased to updated D35002 where fptosi tests were added. That also included re-base to the current master.
No changes in the instcombine results for these added tests though.

Added mixed clamp tests with fptosi.

Compare types instead of their sizes to decide if CastInst is needed.

Rebase onto D35002.

Hi @efriedma, original commit caused the failure under UBSan. The latest uploaded revision fixes it.
Can you please take a look and say if it's ok?

• Fix UBSan error after D33186/r306525.

In D32994#793670, @spatel wrote:

Remove the '-o -' too?

Just curious: why only these files? The problem occurs in hundreds of tests from what I can tell. Shouldn't we fix all of them?

• Remove "-o -" too.