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.
+                         exp, const1));
+      /* Combine the values together.  */
+ specials = fold_build3_loc (loc, COND_EXPR, int_type, zero_check, fp_zero,
+           fold_build3_loc (loc, COND_EXPR, int_type, exp_lsb_set,
+ fold_build3_loc (loc, COND_EXPR, int_type, mantissa_any_set,
+              HONOR_NANS (mode) ? fp_nan : fp_normal,
+              HONOR_INFINITIES (mode) ? fp_infinite : fp_normal),
+            fp_subnormal));
So this implies you're running on generic, not gimple, right? Otherwise you can't generate these kinds of expressions.

Yes this is generic.

diff --git a/gcc/real.h b/gcc/real.h
index 59af580e78f2637be84f71b98b45ec6611053222..36ded57cf4db7c30c935bdb24219a167480f39c8 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -161,6 +161,15 @@ struct real_format
   bool has_signed_zero;
   bool qnan_msb_set;
   bool canonical_nan_lsbs_set;
+ /* This flag indicates whether the format can be used in the optimized
+     code paths for the __builtin_fpclassify function and friends.
+ The format has to have the same NaN and INF representation as normal + IEEE floats (e.g. exp must have all bits set), most significant bit must be + sign bit, followed by exp bits of at most 32 bits. Lastly the floating + point number must be representable as an integer. The base of the number
+     also must be base 2.  */
+  bool is_binary_ieee_compatible;
   const char *name;
I think Joseph has already commented on the contents of the initializer and a few more cases were we can use the optimized paths.

However, I do have a general question. There are some targets which have FPUs that are basically IEEE, but don't support certain IEEE features like NaNs, denorms, etc.

Presumably all that's needed is for those targets to define a hook to describe which checks will always be false and you can check the hook's return value. Right?

Yes, that should be enough. Not supporting NAN and Infinities is already supported though, but it's tied to the real format rather than a particular target.

Can you please include some tests to verify you're getting the initial code generation you want? Ideally there'd be execution tests too where you generate one of the special nodes, then call the __builtin and verify that you get the expected results back. The latter in particular are key since it'll allow us to catch problems much earlier across the wide variety of targets GCC supports.

I can add some code generation tests. There are I believe already some execution tests, which test both correct and incorrect output.

I think you already had plans to post an updated patch. Please include the fixes noted above in that update.

Yes I will include your feedback in it. I'm currently waiting for some extra performance numbers.


Reply via email to