https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118267
--- Comment #3 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- The blocks are ineligible for ifcombine because the dereferences could trap. Some flow-dependent information could enable us to conclude that only the first dereference could trap, and it would remain in place, but ifcombine doesn't have that. And then, there's the third compare, already optimized to a load. It could conceivably be conceptually turned back into a compare for ifcombine to consider, but the fact that the PHI value for that block is variable and differs from the PHI values for the other blocks would deviate from current ifcombine requirements.
