Re: [PATCH] Use CONVERT_EXPR_P and friends in the middle-end
On Fri, Oct 31, 2014 at 6:59 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Fri, 31 Oct 2014, Richard Biener wrote: This fixes the few places where explicit checks for NOP_EXPR or CONVERT_EXPRs crept in. The goal really should be to eliminate anything that distinguishes the two, and then combine them (eliminate NOP_EXPR) (as I said in https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01975.html). Yes, A noticable change may be the tree-eh.c one where we previously considered FP NOP_EXPRs trapping if flag_trapping_math (Any fp arithmetic may trap) but now like FP CONVERT_EXPRs only when honor_nans (but for some reason the honor_nans cases don't check flag_trapping_math). I'm not 100% sure which variant is more correct (this is FP - FP conversions thus widenings, truncations, converts from/to DFP). Well, use of honor_nans there is confused. (honor_nans is set in operation_could_trap_p in a way that checks flag_trapping_math !flag_finite_math_only - but doesn't check HONOR_NANS on the relevant floating-point mode.) Setting aside for the moment that -ftrapping-math covers both cases where actual trap handlers are called, and cases where exception flags are set without calling trap handlers (the latter being the only one covered by ISO C at present), the following applies: * Conversions of quiet NaNs from one floating-point type to another do not raise exceptions. Conversions of signaling NaNs do, however, and conversions of finite values can raise inexact (except for widening from a narrower to a wider type with the same radix) and underflow (except for widening, again, and with an exception to the exception in the case of __float80 to __float128 conversion with underflow traps enabled). * Conversions from floating point to integer (FIX_TRUNC_EXPR) do however raise invalid for NaN (or infinite) arguments - and for finite arguments outside the range of the destination type (this includes -1 and below converted to unsigned types). Whether they raise inexact for non-integer arguments is unspecified. To a first approximation, even with -ffinite-math-only, assume with -ftrapping-math that invalid may be raised for such conversions because of out-of-range values (although the range of binary16 - currently only supported as ARM __fp16 - is narrow enough that if you ignore non-finite values, conversions to some signed integer types are guaranteed in-range). It looks like the honor_nans argument was intended for the case of ordered conversions, for which it's correct that quiet NaNs raise exceptions, and is being misused for conversions, where fp_operation flag_trapping_math is the right thing to check (although there are certain subcases, depending on the types involved, where in fact you can't have traps). That in turn is the default, suggesting just removing the CASE_CONVERT and FIX_TRUNC_EXPR cases (the effect of which is to treat certain conversions as trapping for -ffinite-math-only where previously they weren't treated as trapping). Ok, I'll test a patch doing that. Thanks, Richard. -- Joseph S. Myers jos...@codesourcery.com
[PATCH] Use CONVERT_EXPR_P and friends in the middle-end
This fixes the few places where explicit checks for NOP_EXPR or CONVERT_EXPRs crept in. A noticable change may be the tree-eh.c one where we previously considered FP NOP_EXPRs trapping if flag_trapping_math (Any fp arithmetic may trap) but now like FP CONVERT_EXPRs only when honor_nans (but for some reason the honor_nans cases don't check flag_trapping_math). I'm not 100% sure which variant is more correct (this is FP - FP conversions thus widenings, truncations, converts from/to DFP). Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2014-10-31 Richard Biener rguent...@suse.de * builtins.c (fold_builtin_atomic_always_lock_free): Use CONVERT_EXPR_P, CONVERT_EXPR_CODE_P and CASE_CONVERT where approprate. (fold_builtin_expect): Likewise. (integer_valued_real_p): Likewise. * cfgexpand.c (expand_debug_expr): Likewise. * ipa-inline-analysis.c (eliminated_by_inlining_prob): Likewise. (find_foldable_builtin_expect): Likewise. * trans-mem.c (thread_private_new_memory): Likewise. * tree-affine.c (aff_combination_expand): Likewise. * tree-data-ref.c (initialize_matrix_A): Likewise. * tree-eh.c (operation_could_trap_helper_p): Likewise. * tree-inline.c (copy_bb): Likewise. * tree-pretty-print.c (dump_function_name): Likewise. (print_call_name): Likewise. * tree-ssa-forwprop.c (constant_pointer_difference): Likewise. * tree-ssa-math-opts.c (find_bswap_or_nop_1): Likewise. * tree-vect-generic.c (expand_vector_operations_1): Likewise. * tree-vect-patterns.c (vect_handle_widen_op_by_const): Likewise. (vect_recog_widen_mult_pattern): Likewise. (vect_operation_fits_smaller_type): Likewise. * tree-vrp.c (find_assert_locations_1): Likewise. * tree-ssa-dom.c (initialize_hash_element): Canonicalize converts to NOP_EXPR. p3 Description: Binary data
Re: [PATCH] Use CONVERT_EXPR_P and friends in the middle-end
On Fri, 31 Oct 2014, Richard Biener wrote: This fixes the few places where explicit checks for NOP_EXPR or CONVERT_EXPRs crept in. The goal really should be to eliminate anything that distinguishes the two, and then combine them (eliminate NOP_EXPR) (as I said in https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01975.html). A noticable change may be the tree-eh.c one where we previously considered FP NOP_EXPRs trapping if flag_trapping_math (Any fp arithmetic may trap) but now like FP CONVERT_EXPRs only when honor_nans (but for some reason the honor_nans cases don't check flag_trapping_math). I'm not 100% sure which variant is more correct (this is FP - FP conversions thus widenings, truncations, converts from/to DFP). Well, use of honor_nans there is confused. (honor_nans is set in operation_could_trap_p in a way that checks flag_trapping_math !flag_finite_math_only - but doesn't check HONOR_NANS on the relevant floating-point mode.) Setting aside for the moment that -ftrapping-math covers both cases where actual trap handlers are called, and cases where exception flags are set without calling trap handlers (the latter being the only one covered by ISO C at present), the following applies: * Conversions of quiet NaNs from one floating-point type to another do not raise exceptions. Conversions of signaling NaNs do, however, and conversions of finite values can raise inexact (except for widening from a narrower to a wider type with the same radix) and underflow (except for widening, again, and with an exception to the exception in the case of __float80 to __float128 conversion with underflow traps enabled). * Conversions from floating point to integer (FIX_TRUNC_EXPR) do however raise invalid for NaN (or infinite) arguments - and for finite arguments outside the range of the destination type (this includes -1 and below converted to unsigned types). Whether they raise inexact for non-integer arguments is unspecified. To a first approximation, even with -ffinite-math-only, assume with -ftrapping-math that invalid may be raised for such conversions because of out-of-range values (although the range of binary16 - currently only supported as ARM __fp16 - is narrow enough that if you ignore non-finite values, conversions to some signed integer types are guaranteed in-range). It looks like the honor_nans argument was intended for the case of ordered conversions, for which it's correct that quiet NaNs raise exceptions, and is being misused for conversions, where fp_operation flag_trapping_math is the right thing to check (although there are certain subcases, depending on the types involved, where in fact you can't have traps). That in turn is the default, suggesting just removing the CASE_CONVERT and FIX_TRUNC_EXPR cases (the effect of which is to treat certain conversions as trapping for -ffinite-math-only where previously they weren't treated as trapping). -- Joseph S. Myers jos...@codesourcery.com
