https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 21 Feb 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 > > --- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > So, either we could somehow handle that case during expansion (treat it > basically as VCE), or tweak the > /* For integral conversions with the same precision or pointer > conversions use a NOP_EXPR instead. */ > (simplify > (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))) > (convert @0))) > match.pd rule not to do that for INTEGER_TYPEs with PRECISION > > MAX_FIXED_TYPE_PRECISION (then we don't need the gimple-lower-bitint.cc > changes > either). > --- gcc/match.pd.jj 2024-02-19 09:42:16.583617451 +0100 > +++ gcc/match.pd 2024-02-21 13:32:06.567816298 +0100 > @@ -4679,7 +4679,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)) > + /* Punt for conversions from or to barely supported huge > + INTEGER_TYPEs. Those can handle just loads/stores/moves but > + nothing else. */ > + && (TYPE_PRECISION (type) <= MAX_FIXED_MODE_SIZE > + || (TREE_CODE (type) != INTEGER_TYPE > + && TREE_CODE (TREE_TYPE (@0)) != INTEGER_TYPE))) > (convert @0))) > > /* Strip inner integral conversions that do not change precision or size, or I think the usual BLKmode check would be better here? Apart from that this looks correct, we shouldn't use a regular convert on a non-register type. In fact, it looks like all bitint types are register types because we want SSA names for them. A bit of a "bad" design ... We've used BLKmode checks elsewhere so I think it would be appropriate here, too.
