This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add a new macro to mask a float
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>, <munroesj at linux dot vnet dot ibm dot com>
- Date: Tue, 28 Jun 2016 21:00:52 +0000
- Subject: Re: [PATCH] Add a new macro to mask a float
- Authentication-results: sourceware.org; auth=none
- References: <1467142073-13886-1-git-send-email-tuliom at linux dot vnet dot ibm dot com>
On Tue, 28 Jun 2016, Tulio Magno Quites Machado Filho wrote:
> +/* Faster to do an in-place masking of the float number in the VSR
> + than move to GPR for the masking and back. maskl, maskr, and maski
> + are used to convert the 32-bit "mask" parameter to a 64-bit mask
> + suitable for the internal representation of a scalar
> + single-precision floating point number in the Power8 processor.
> + Note: before applying the mask, xvmovdp is used to ensure f is
> + normalized. */
Actually, could you clarify what that internal representation is, and what
"to ensure f is normalized" is about? Is this macro definition exactly
equivalent to the integer masking, including for subnormal arguments and
NaNs?
If it's exactly equivalent in all cases, including subnormals and NaNs,
then my previous comment applies - it would be better as a compiler
optimization. If it's only equivalent for normal values but the code in
question can't get subnormal arguments / NaNs / whatever values it's not
equivalent for, then doing this in glibc is more plausible, though there
are coding style issues, the macro comments would need to explain the
limitation, and it would be necessary to be sure in each case that problem
arguments can't get there.
--
Joseph S. Myers
joseph@codesourcery.com