https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #59 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, can't we combine
--- gcc/match.pd.jj 2021-02-18 16:21:01.000000000 +0100
+++ gcc/match.pd 2021-02-23 12:39:32.801064905 +0100
@@ -3316,7 +3316,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(view_convert @0)
(if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type))
&& (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE
(@0)))
- && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0)))
+ && (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))
+ || (TREE_CODE (type) == BOOLEAN_TYPE
+ && TREE_CODE (@0) == SSA_NAME
+ && TREE_CODE (TREE_TYPE (@0)) != BOOLEAN_TYPE
+ && TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (@0))
+ && type_has_mode_precision_p (TREE_TYPE (@0))
+ && ssa_name_has_boolean_range (@0))))
(convert @0)))
/* Strip inner integral conversions that do not change precision or size, or
with expander optimization that will optimize away that masking when expanding
NOP_EXPR from integral SSA_NAME with ssa_name_has_boolean_range to bool?
Note, on this testcase the NOP_EXPR to bool is optimized away, so the expansion
change would make zero difference, so I'll need to test that without the above
change and doing the VCE -> NOP optimization during TER or so to see it in
action. Anyway, when I did it earlier today, while expansion emitted the AND
1, later optimizations optimized that away again.
