Missed canonicalizations for losslessness checks of unsigned integer demotions

[LebedevRI]

Bugzilla Link	44100
Version	trunk
OS	Linux
CC	@annamthomas,@RKSimon,@rotateright,@TNorthover
Fixed by commit(s)	0f22e78

Extended Description

Given

unsigned short t0(unsigned short x) {
x+=1;
return x;
}
unsigned short t1(unsigned short x) {
x-=1;
return x;
}

With -fsanitize=implicit-conversion we produce:

%3 = add nuw nsw i32 %2, 1, !dbg !​15
%4 = trunc i32 %3 to i16, !dbg !​15
%5 = icmp ult i32 %3, 65536, !dbg !​15

and

%2 = zext i16 %0 to i32, !dbg !​22
%3 = add nsw i32 %2, -1, !dbg !​22
%4 = trunc i32 %3 to i16, !dbg !​22
%5 = icmp ult i32 %3, 65536, !dbg !​22

https://godbolt.org/z/Us33sA

But in these cases we can simply check the original %2:

Name: unsigned truncation check - increment
Pre: C2 u>= C1
%add = add nuw i32 %conv, C1 ; has extra uses
%cmp = icmp ult i32 %add, C2 ; is truncation NUW?
=>
%cmp = icmp ult i32 %conv, (C2-C1)

Name: unsigned truncation check - decrement
Pre: C1 <= 0 ; C1 is non-positive
%conv = zext i16 %x to i32
%add = add i32 %conv, C1 ; has extra uses
%cmp = icmp ult i32 %add, 65536 ; is truncation NUW?
=>
%cmp = icmp uge i32 %conv, -C1

https://rise4fun.com/Alive/x35G

[LebedevRI]

And similarly, we have

%2 = zext i16 %0 to i32, !dbg !​15 ; or sext
%3 = add nuw nsw i32 %2, 1, !dbg !​15
%4 = trunc i32 %3 to i16, !dbg !​15

At least for constant RHS, we could 'freely' replace %4 with a single add:

Name: zext-add-trunc -> trunc-add
%conv = zext i16 %x to i32
%inc = add i32 %conv, %y
%conv1 = trunc i32 %inc to i16
=>
%C1_trunc = trunc i32 %y to i16
%conv1 = add i16 %x, %C1_trunc

... same for sub/mul, and same for sext

https://rise4fun.com/Alive/54
https://rise4fun.com/Alive/jnW

I'm guessing currently we don't do that because there are other uses of the existing add?
Not sure whether this is a good idea or not.

[LebedevRI]

Given

unsigned short t0(unsigned short x) {
x+=1;
return x;
}

With -fsanitize=implicit-conversion we produce:

%3 = add nuw nsw i32 %2, 1, !dbg !​15
%4 = trunc i32 %3 to i16, !dbg !​15
%5 = icmp ult i32 %3, 65536, !dbg !​15

https://godbolt.org/z/Us33sA

But in these cases we can simply check the original %2:

Name: unsigned truncation check - increment
Pre: C2 u>= C1
%add = add nuw i32 %conv, C1 ; has extra uses
%cmp = icmp ult i32 %add, C2 ; is truncation NUW?
=>
%cmp = icmp ult i32 %conv, (C2-C1)

And this actually got regressed by overzealous one-use check @ https://reviews.llvm.org/rL341831

[LebedevRI]

Given

unsigned short t0(unsigned short x) {
x+=1;
return x;
}

With -fsanitize=implicit-conversion we produce:

%3 = add nuw nsw i32 %2, 1, !dbg !​15
%4 = trunc i32 %3 to i16, !dbg !​15
%5 = icmp ult i32 %3, 65536, !dbg !​15

https://godbolt.org/z/Us33sA

But in these cases we can simply check the original %2:

Name: unsigned truncation check - increment
Pre: C2 u>= C1
%add = add nuw i32 %conv, C1 ; has extra uses
%cmp = icmp ult i32 %add, C2 ; is truncation NUW?
=>
%cmp = icmp ult i32 %conv, (C2-C1)

And this actually got regressed by overzealous one-use check @
https://reviews.llvm.org/rL341831

... which is now reverted in 0f22e78.

[LebedevRI]

Name: unsigned truncation check - increment
Pre: C2 u>= C1
%add = add nuw i32 %conv, C1 ; has extra uses
%cmp = icmp ult i32 %add, C2 ; is truncation NUW?
=>
%cmp = icmp ult i32 %conv, (C2-C1)

Name: unsigned truncation check - decrement
Pre: C1 <= 0 ; C1 is non-positive
%conv = zext i16 %x to i32
%add = add i32 %conv, C1 ; has extra uses
%cmp = icmp ult i32 %add, 65536 ; is truncation NUW?
=>
%cmp = icmp uge i32 %conv, -C1

https://rise4fun.com/Alive/x35G

Thinking about it more, somewhat more general form would be:

Name: unsigned truncation check - decrement
Pre: C0 u< C2 && C1 <= 0 && C2 >= 0
%add = add nsw i32 C0, C1 ; has extra uses
%cmp = icmp ult i32 %add, C2 ; is truncation NUW?
=>
%cmp = icmp uge i32 C0, -C1

where in C0 u< C2 as C0 we can take ~(KnownBits(C0).Zero)
I'm not seeing more general generalization for this.

https://rise4fun.com/Alive/pCvs

[LebedevRI]

mentioned in issue llvm/llvm-bugzilla-archive#44102

[annamthomas]

mentioned in issue llvm/llvm-bugzilla-archive#44899

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#46924