On Mon, 26 Jun 2023, Robin Dapp wrote: > 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?
The element_mode passing is OK. We don't do a target support check in any other place when non-vector operations are involved. Can you push the element_mode change separately please? I'd like to hear more reasoning of why target_supports_op_p is wanted here. Doesn't target_supports_op_p return false if this is for example a soft-fp target? So if at all, shouldn't the test only be carried out if the original operation was supported by the target? Thanks, Richard. > 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) > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
