https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117542
--- Comment #2 from Hongtao Liu <liuhongt at gcc dot gnu.org> --- (In reply to Richard Biener from comment #1) > It doesn't even unambiguously specify whether the mode is that of the source > or the destination. The original idea was of course that the size > unambiguously specifies the destination mode and thus specifying it would be > redundant. Making > all those optabs conversion optabs has some overhead and is useless in 99% of > the cases. > > Can you combine both destination mode variants in vec_pack_trunc_VnSF and > use predicates to select? Then the mode of operand[0] will be hided in the predicates, I doubt it would fail below check in supportable_narrowing_operation 4739 if (insn_data[icode1].operand[0].mode == TYPE_MODE (narrow_vectype)) > Or is HF/BF mode support not always both present > or not present? One may exist, both may exist, none may exist. > > You could implement truncVnSFVnBF which helps in some cases. > It's already in the trunk. > I would expect aarch64 has the same issue. Yes.
