I'm not sure if this is the only problem, and I'm also not sure about our rules for pointer comparison, but this seems like a missing constant fold opportunity:

define i1 @​#49355 (i8* %x) {
%cmp = icmp ule i8 (...)* null, bitcast (i1 (i8*)* @​#49355 to i8 (...)*)
ret i1 %cmp
}

$ ./opt -instsimplify cmp_null_const_expr.ll -S
define i1 @​#49355 (i8* %x) {
ret i1 icmp uge (i8 (...)* bitcast (i1 (i8*)* @​#49355 to i8 (...)), i8 (...) null)
}

I'm not sure if this is the only problem, and I'm also not sure about our
rules for pointer comparison, but this seems like a missing constant fold
opportunity:

define i1 @​#49355 (i8* %x) {
%cmp = icmp ule i8 (...)* null, bitcast (i1 (i8*)* @​#49355 to i8 (...)*)
ret i1 %cmp
}

$ ./opt -instsimplify cmp_null_const_expr.ll -S
define i1 @​#49355 (i8* %x) {
ret i1 icmp uge (i8 (...)* bitcast (i1 (i8*)* @​#49355 to i8 (...)), i8
(...) null)
}

https://reviews.llvm.org/rGf75b5305f4de

That should at least allow us to reduce the test to only "opt -instcombine". I had a machine working on bugpoint reducing that for over an hour, but it failed when I updated 'opt' while working on another bug. I'll try reducing again later.

Bugpoint was spinning away at this for 8+ hours on my machine.

The test is triggering some iterative transform - increasing the iteration limit will avoid the assert (the function will "finish" optimizing within instcombine).

We can also decrease the iteration limit to create a smaller example with bugpoint:

$ bugpoint -instcombine 49355.ll -run-llc --opt-args -instcombine-infinite-loop-threshold=8

But it doesn't look like bug 49122 and related bugs that I've diagnosed. There are no stores in the code. Something else is going on.

reduced test for instcombine
Asserts with:
$ opt 49355iter8.ll -S -instcombine -instcombine-infinite-loop-threshold=8

(but completes at iteration 9)

No longer reproduces, presumably fixed by single-iteration InstCombine work.