Re: [PATCH] Switch vec_init and vec_extract optabs to 2 mode optab to allow extraction of vector from vector or initialization of vector from smaller vectors (PR target/80846)

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi Jakub,

On Tue, Jul 25, 2017 at 11:14:32AM +0200, Jakub Jelinek wrote:
> The following patch adjusts the vec_init and vec_extract optabs, so that
> they don't have in the expander names just the vector mode, but also another
> mode, for vec_extract the mode of the result and for vec_init the mode of
> the elts of the vector passed as second operand.
> 
> Without this patch, the second mode has been implicit, GET_MODE_INNER of
> the vector mode, so one could just extract a single element from a vector
> or construct vector from elements.  While that is most common, we allow
> in GIMPLE e.g. construction of V8DImode from 4 V2DImode elements etc.
> and the vectorizer uses them.  By having the second mode in the name
> it allows the generic code (vectorizer, expansion) to query whether the
> backend supports such vector from vector expansions or inits from vector
> elts and use them if available.
> 
> For vec_extract, if we say want to extract high V2SImode from V4SImode
> the fallback is try to expand it as DImode extraction from V2DImode.
> This works well in many cases, but doesn't really work for very large
> vectors, say if we want to extract high V8SImode from V16SImode on x86,
> we'd need OImode extraction from V2OImode, which is something the backend
> doesn't have any support for.
> For vec_init, the fallback is usually to go through memory, which is slow in
> many cases.
> 
> This patch only adds new vector from vector extract and init patterns to
> the i386 backend, but I had to change many other targets too, because
> it needs to have the element mode in the vec_extract/vec_init expander
> names.  Seems most of the backends didn't really have a mode attribute
> usable for this or had it only in uppercase, while for the names we need
> lowercase.  Some backends had a convention on how to name lower case
> vs. upper case modes, others didn't have any.  So I'm CCing maintainers
> of affected backends to seek advice on what mode attributes they want to
> use.

Would it be possible (and useful) to _also_ keep the old names?  Or do
you expect all targets will want to support all combinations?

> --- gcc/config/rs6000/vector.md.jj	2017-06-08 20:50:49.000000000 +0200
> +++ gcc/config/rs6000/vector.md	2017-07-24 17:44:44.699580927 +0200
> @@ -74,6 +74,16 @@ (define_mode_attr VEC_base [(V16QI "QI")
>  			    (V1TI  "TI")
>  			    (TI    "TI")])
>  
> +;; As above, but in lower case
> +(define_mode_attr VEC_base_l [(V16QI "qi")
> +			      (V8HI  "hi")
> +			      (V4SI  "si")
> +			      (V2DI  "di")
> +			      (V4SF  "sf")
> +			      (V2DF  "df")
> +			      (V1TI  "ti")
> +			      (TI    "ti")])
> +
>  ;; Same size integer type for floating point data
>  (define_mode_attr VEC_int [(V4SF  "v4si")
>  			   (V2DF  "v2di")])

> @@ -520,6 +520,17 @@ (define_mode_attr VEL [(V8QI "QI") (V16Q
>  			(SI   "SI") (HI   "HI")
>  			(QI   "QI")])
>  
> +;; Define element mode for each vector mode (lower case).
> +(define_mode_attr Vel [(V8QI "qi") (V16QI "qi")
> +			(V4HI "hi") (V8HI "hi")
> +			(V2SI "si") (V4SI "si")
> +			(DI "di")   (V2DI "di")
> +			(V4HF "hf") (V8HF "hf")
> +			(V2SF "sf") (V4SF "sf")
> +			(V2DF "df") (DF "df")
> +			(SI   "si") (HI   "hi")
> +			(QI   "qi")])

(Inconsistent spacing, please fix).

("vel" instead of "Vel" for this name?)

How is this different from VEC_base_l?  They can just be merged it seems.
(And for that matter, VEC_base and VEL as well).  We'll handle that I
suppose, don't let it hold up this patch :-)


Segher