@Carrot created an issue with the hang reproducer: https://github.com/llvm/llvm-project/issues/67188

This patch also seems to cause near-infinite compile times in same cases (don't know if they actually finish as the process gets killed via OoM). Trying to get a reproducer now.

Not exactly familiar with this part of code, but the fix makes sense to me.
Perhaps we could add a check that OrderedRoots is topologically sorted under EXPENSIVE_CHECKS.

Superseded by D159209

In D57059#3775511, @ABataev wrote:

In D57059#3775369, @xbolva00 wrote:

Current status?

Still requires several patches to commit.

LGTM

In D155734#4516890, @pengfei wrote:

LGTM. If possible, you could add new test on the end of the file, so that you won't get a lot of BB number changes.

Okay, but then add an aarch64 maintainer on the review list (also add phoebe on this one).

In D155734#4516168, @goldstein.w.n wrote:

Your change is x86 only. Why are you adding aarch64 tests?

split new tests pre-changes into separate review

Remove updates to aarch64 test

Add test with masked nbits

Having the issues with PTRACE_SEIZE on CentOS 6 (will probably need to build LLVM where for around a year). Don't use llvm-exegesis there, but it's hard to cleanly disable it from build, since tests depend on it.

LGTM

Simplified the test

Discovered when some downstream analysis wasn't invalidated when this transformation was the only change instcombine made leading to a miscompile. Not sure how to write a good test for this. I remember there being a pass that verified that passes correctly reported changed IR but I think it only worked for legacy pm.

I've experienced similar linking issues (-lz not resolved) when cross-compiling since ZLIB was initially picked from cross-build sysroot with a full path but simply using -lz is not enough to find a target zlib.

Simplified lit test a little

LGTM

In D127744#3581771, @reames wrote:

Non blocking comment..

freeze(undef) being equally null or base as undef seems questionable to me. I think in practice it might work out okay, but there's no guarantee that the value chosen for undef isn't 0 when frozen, and 1 when not. You might want to step back and take a deeper look at the problem you're solving here.

@efriedma I've added float->bloat16 conversion tests but I'm not sure these are exact same you had in mind.

Added float->bfloat conversion tests

Submitted an alternative solution (adjusting the shift/exponent)

In D127140#3561467, @efriedma wrote:

I'm not sure it's safe to assume that the lost fraction is lfLessThanHalf, in general. At least, it isn't obvious to me, particularly for cases involving bfloat.

We already have a bunch of code to adjust the shift amount for truncations: the "If this is a truncation of a denormal number [...]" block. Can we adjust that code to reduce the shift amount in this case?

Addressed the comments