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

Reply via email to