https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #7 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to rsand...@gcc.gnu.org from comment #6) > (In reply to Tamar Christina from comment #3) > > The vectorizer has this context but since we didn't want a new IFN the > > context should instead be derivable in > > targetm.vectorize.can_special_div_by_const hook. > I probably got lost in the threading, but could you point to where > the idea of using an ifn was rejected? I know there was pushback > against hard-coding a specific constant, but that doesn't prevent > the use of ifns in itself. (E.g. the gather/scatter IFNs have > constant arguments that are checked against what the target allows.) https://patchwork.sourceware.org/project/gcc/patch/patch-15779-ta...@arm.com/#124788 is where the original patch used an IFN. https://patchwork.sourceware.org/project/gcc/patch/patch-15779-ta...@arm.com/#124863 where Richi wouldn't ACK a new optab as it didn't have a physical instruction backing it on any ISA, and in fairness, no one else did either effectively stranding the change. https://patchwork.sourceware.org/project/gcc/patch/patch-15779-ta...@arm.com/#125144 where I pinged and got no response to the ping. After which I went on IRC and asked Richi how he'd like me to proceed. In reply to this I was instructed he would like to proceed the same way vector permutes are currently handled with `can_perm` etc. and that's where the patch thread picks off back on the ML.
