On Fri, Nov 29, 2013 at 11:08 AM, Richard Sandiford
wrote:
> Richard Earnshaw 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 im
Richard Earnshaw 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
>> ex
this is fine.
kenny
On 11/28/2013 12:29 PM, 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 value
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 compar
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 re
