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
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
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
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
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
