https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114121
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #2) > As an aside we at -O3 has: > _87 = .USUBC (_30, 3, 0); > _93 = IMAGPART_EXPR <_87>; > _88 = .USUBC (0, 0, _93); > _29 = IMAGPART_EXPR <_88>; > _187 = .USUBC (0, 0, _29); > _217 = IMAGPART_EXPR <_187>; > _218 = .USUBC (0, 0, _217); > _214 = IMAGPART_EXPR <_218>; > _213 = .USUBC (0, 0, _214); > _212 = IMAGPART_EXPR <_213>; > _200 = .USUBC (0, 0, _212); > _34 = IMAGPART_EXPR <_200>; > _35 = .USUBC (0, 0, _34); > _36 = IMAGPART_EXPR <_35>; > _39 = .USUBC (0, 0, _36); > _40 = REALPART_EXPR <_39>; > _2 = (signed long) _40; > _77 = _2 < 0; > > isn't `.USUBC (0, 0, _93);` just Complex<-_93, _93!=0> ? Or did I > misunderstand USUBC ? It is, but would that result in better generated code in case there is .USUBC (_400, _401, _29); later on? It would be nice to optimize such long series of .USUBC (0, 0, prev) into just copying of the result of the first one such call. For similar long series of .UADDC (0, 0, prev) that would be just the first one and all the rest is 0+0i because it never carries over anymore.