Re: [vect-patterns] Refactor widen_plus/widen_minus as internal_fns

[Richard Biener <rguenther@suse.de>]

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.