Hi,
this patch changes TYPE_MODE into element_mode in a match.pd
simplification. As the simplification can be called with vector types
real_can_shorten_arithmetic would ICE in REAL_MODE_FORMAT which
expects a scalar mode. Therefore, use element_mode instead of
TYPE_MODE.
Additionally, check if the target supports the resulting operation in the
new mode. One target that supports e.g. a float addition but not a
_Float16 addition is the RISC-V vector Float16 extension Zvfhmin.
Bootstrap on x86_64 succeeded, testsuite is currently running. Is this OK
if the testsuite is clean?
Regards
Robin
gcc/ChangeLog:
* match.pd: Use element_mode and check if target supports
operation with new type.
---
gcc/match.pd | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/match.pd b/gcc/match.pd
index 33ccda3e7b6..4a200f221f6 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7454,10 +7454,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
values representable in the TYPE to be within the
range of normal values of ITYPE. */
(if (element_precision (newtype) < element_precision (itype)
+ && target_supports_op_p (newtype, op, optab_default)
&& (flag_unsafe_math_optimizations
|| (element_precision (newtype) == element_precision
(type)
- && real_can_shorten_arithmetic (TYPE_MODE (itype),
- TYPE_MODE (type))
+ && real_can_shorten_arithmetic (element_mode (itype),
+ element_mode (type))
&& !excess_precision_type (newtype)))
&& !types_match (itype, newtype))
(convert:type (op (convert:newtype @1)
--
2.41.0
