On Thu, 11 Nov 2021, Joel Hutton wrote: > Hi all, > > This refactor allows widening vect patterns (such as widen_plus/widen_minus) > to be represented as > either internal_fns or tree_codes and replaces the current > widen_plus/widen_minus with internal_fn versions. This refactor is split into > 3 patches. > > Boostrapped and regression tested on aarch64. > > Ok for stage 3?
IIRC Richard had comments the last round so I'd appreciate if he'd chime in as well. 0001 looks OK to me. diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c index e8fd16b9c21..4ab80d24b89 100644 --- a/gcc/internal-fn.c +++ b/gcc/internal-fn.c @@ -52,6 +52,7 @@ along with GCC; see the file COPYING3. If not see #include "explow.h" #include "rtl-iter.h" #include "gimple-range.h" +#include <map> please use #define INCLUDE_MAP before the system.h include instead. Is it really necessary to build a new std::map for each optab lookup?! That looks quite ugly and inefficient. We'd usually - if necessary at all - build a auto_vec<std::pair<key,data> > and .sort () and .bsearch () it. I'm not sure I understand DEF_INTERNAL_OPTAB_MULTI_FN, neither this cover letter nor the patch ChangeLog explains anything. 0003 looks OK to me. So that leaves 0002 which I don't understand as said above. Richard.
