On Fri, Nov 29, 2013 at 11:08 AM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > 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).
Indeed - to be really useful shortcuts should work with len == 1 instead of just with precision <= HOST_BITS_PER_WIDE_INT. Which usually means handling of result len == 2. Richard. > Thanks, > Richard
