On 09/20/2016 06:00 AM, Tamar Christina wrote:
On 16/09/16 20:49, Jeff Law wrote:
On 09/12/2016 10:19 AM, Tamar Christina wrote:
Hi All,
+
+ /* Re-interpret the float as an unsigned integer type
+ with equal precision. */
+ int_arg_type = build_nonstandard_integer_type (TYPE_PRECISION
(type), 0);
+ int_arg = fold_build1_loc (loc, INDIRECT_REF, int_arg_type,
+ fold_build1_loc (loc, NOP_EXPR,
+ build_pointer_type (int_arg_type),
+ fold_build1_loc (loc, ADDR_EXPR,
+ build_pointer_type (type), arg)));
Doesn't this make ARG addressable? Which in turn means ARG won't be
exposed to the gimple/ssa optimizers. Or is it the case that when
fpclassify is used its argument is already in memory (and thus
addressable?)
I believe that it is the case that when fpclassify is use the argument
is already addressable, but I am not 100% certain. I may be able to do
this differently so I'll come back to you on this one.
The more I think about it, the more I suspect ARG is only going to
already be marked as addressable if it has already had its address taken.
But I think we can look at this as an opportunity. If ARG is already
addressable, then it's most likely going to be living in memory (there
are exceptions). If ARG is most likely going to be living in memory,
then we clearly want to use your fast integer path, regardless of the
target.
If ARG is not addressable, then it's not as clear as the object is
likely going to be assigned into an FP register. Integer operations on
the an FP register likely will force a sequence where we dump the
register into memory, load from memory into a GPR, then bit test on the
GPR. That gets very expensive on some architectures.
Could we defer lowering in the case where the object is not addressable
until gimple->rtl expansion time? That's the best time to introduce
target dependencies into the code we generate.
Jeff
