Richard Biener <rguent...@suse.de> writes: > On Wed, 13 Apr 2022, Richard Sandiford wrote: > >> Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> > The following reverts the original PR105140 fix and goes for instead >> > applying the additional fold_convert constraint for VECTOR_TYPE >> > conversions also to fold_convertible_p. I did not try sanitizing >> > all of this at this point. >> > >> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. >> > >> > 2022-04-13 Richard Biener <rguent...@suse.de> >> > >> > PR tree-optimization/105250 >> > * fold-const.cc (fold_convertible_p): Revert >> > r12-7979-geaaf77dd85c333, instead check for size equality >> > of the vector types involved. >> >> This doesn't look right, and I think it'll break SVE. For one >> thing, the tree_int_cst_equal check is bound to fail for >> variable-length vectors. >> >> But also, the idea was to allow element-wise conversions between >> different vector sizes. For example, you can do a nop/convert >> from V4SI to V4DI, which converts 4 SIs to 4 DIs. This is used >> a lot for conversions to and from “partial” SVE vectors, where smaller >> elements are stored in wider containers. > > But fold_convertible_p is used as guard for fold_convert in a lot of > places and that will simply ICE when there's a mismatch in size > as can be seen in the testcase. Note the code as before the > previous fix couldn't really have worked as expected. Is there any > testcase that will "break" now? > > I realize the fold_convertible_p comment says "using a NOP_EXPR" which > means it might conver a narrower set of conversions than fold_convert > (which will happily use FLOAT_EXPR and friends), but still it should > allow fold_convert to build the conversion.
Ah, right, sorry for the false alarm. I'd read the comment as saying that it determined when nop/convert_exprs were valid, rather than whether fold_convert could handle them. > The alternative would have been to emit a NOP_EXPR from fold_convert > for vector type conversions (with the correct constraints), but then > not all targets support those, so we'd need a target support check > in fold_convertible_p then? Yeah, I guess it makes sense to keep things as they are, with code that is aware of these vector conversions using supportable_convert_operation. It tests fine on SVE, as you expected. Thanks, Richard
