Investigate where generation of overflow intrinsics is not profitable

[vladimirradosavljevic]

Currently, in some cases it is not profitable to generate overflow intrinsics in CodeGenPrepare::combineToUAddWithOverflow and CodeGenPrepare::combineToUSubWithOverflow (note that for the latter function, generation of overflow intrinsics is disabled atm since TLI->shouldFormOverflowOp return false for SUB).
For the following example:

define i256 @add_overflow(i256 %a) {
entry:
  %c = icmp eq i256 %a, -1
  %l = add i256 %a, 1
  %0 = icmp eq i256 %l, 0
  br i1 %0, label %then, label %else

then:                                             ; preds = %entry
  ret i256 0

else:                                             ; preds = %entry
  ret i256 %l
}

If overflow intrinsic is generated from the a + 1 == 0, we are generating following assembly instructions:

add_overflow:                           ; @add_overflow
; %bb.0:                                ; %entry
	add!	1, r1, r2
	jump.lt	@.BB0_2
; %bb.1:                                ; %else
	add	1, r1, r1
	ret
.BB0_2:                                 ; %then
	add	r0, r0, r1
	ret

In case overflow intrinsics is not generated, we are generating:

add_overflow:                           ; @add_overflow
; %bb.0:                                ; %entry
	add!	1, r1, r1
	add.eq	r0, r0, r1
; %bb.1:                                ; %else
	ret

Reason for this could be #590 or that we don't have inverse condition code for overflow flags, but that is something to investigate.