Richard Earnshaw <rearn...@arm.com> writes: > On 28/11/13 17:29, Richard Sandiford wrote: >> The existing ltu_p fast path can handle any pairs of single-HWI inputs, >> even for precision > HOST_BITS_PER_WIDE_INT. In that case both xl and >> yl are implicitly sign-extended to the larger precision, but with the >> extended values still being compared as unsigned. The extension doesn't >> change the result in that case. >> >> When compiling a recent fold-const.ii, this reduces the number of >> ltu_p_large calls from 23849 to 697. >> > > Are these sorts of nuggets of information going to be recorded anywhere?
You mean put the fold-const.ii numbers in a comment? I could if you like, but it's really just a general principle that checking for two len == 1 integers catches more cases than checking for the precision being <= HOST_BITS_PER_WIDE_INT. Every precision <= HOST_BITS_PER_WIDE_INT will have a length of 1, but many integers with a length of 1 have a precision > HOST_BITS_PER_WIDE_INT (because of offset_int and widest_int). Thanks, Richard
