Re: Don't query the frontend for unsupported types

[Richard Biener <richard.guenther@gmail.com>]

On September 20, 2017 2:36:03 PM GMT+02:00, Richard Sandiford <richard.sandiford@linaro.org> wrote:
>When forcing a constant of mode MODE into memory, force_const_mem
>asks the frontend to provide the type associated with that mode.
>In principle type_for_mode is allowed to return null, and although
>one use site correctly handled that, the other didn't.
>
>I think there's agreement that it's bogus to use type_for_mode for
>this kind of thing, since it forces frontends to handle types that
>don't exist in that language.  See e.g. http://gcc.gnu.org/PR46805
>where the Go frontend was forced to handle vector types even though
>Go doesn't have vector types.
>
>Also, the frontends use code like:
>
>  else if (VECTOR_MODE_P (mode))
>    {
>      machine_mode inner_mode = GET_MODE_INNER (mode);
>      tree inner_type = c_common_type_for_mode (inner_mode, unsignedp);
>      if (inner_type != NULL_TREE)
>        return build_vector_type_for_mode (inner_type, mode);
>    }
>
>and there's no guarantee that every vector mode M used by backend
>rtl has an associated vector type whose TYPE_MODE is M.  I think
>really the type_for_mode hook should only return trees that _do_ have
>the requested TYPE_MODE, but PR46805 linked above shows that this is
>likely to have too many knock-on consequences.  It doesn't make sense
>for force_const_mem to ask about vector modes that aren't valid for
>vector types, so this patch handles the condition there instead.
>
>This is needed for SVE multi-register modes, which are modelled as
>vector modes but are not usable as vector types.
>
>Tested on aarch64-linux-gnu, x86_64-linux-gnu and
>powerpc64le-linus-gnu.
>OK to install?

I think we should get rid of the use entirely. 

Richard. 

>Richard
>
>
>2017-09-20  Richard Sandiford  <richard.sandiford@linaro.org>
>	    Alan Hayward  <alan.hayward@arm.com>
>	    David Sherwood  <david.sherwood@arm.com>
>
>gcc/
>	* varasm.c (force_const_mem): Don't ask the front end about
>	vector modes that are not supported as vector types by the target.
>
>Index: gcc/varasm.c
>===================================================================
>--- gcc/varasm.c	2017-09-12 14:28:56.402824780 +0100
>+++ gcc/varasm.c	2017-09-20 13:33:15.942547232 +0100
>@@ -3785,10 +3785,17 @@ force_const_mem (machine_mode mode, rtx
>   desc = ggc_alloc<constant_descriptor_rtx> ();
>   *slot = desc;
> 
>+  tree type = NULL_TREE;
>+  if (mode != VOIDmode
>+      /* Don't ask the frontend about vector modes if there cannot be
>a
>+	 VECTOR_TYPE whose TYPE_MODE is MODE.  */
>+      && (!VECTOR_MODE_P (mode)
>+	  || targetm.vector_mode_supported_p (mode)))
>+    type = lang_hooks.types.type_for_mode (mode, 0);
>+
>   /* Align the location counter as required by EXP's data type.  */
>   align = GET_MODE_ALIGNMENT (mode == VOIDmode ? word_mode : mode);
> 
>-  tree type = lang_hooks.types.type_for_mode (mode, 0);
>   if (type != NULL_TREE)
>     align = CONSTANT_ALIGNMENT (make_tree (type, x), align);
> 
>@@ -3832,7 +3839,8 @@ force_const_mem (machine_mode mode, rtx
> 
>   /* Construct the MEM.  */
>   desc->mem = def = gen_const_mem (mode, symbol);
>-  set_mem_attributes (def, lang_hooks.types.type_for_mode (mode, 0),
>1);
>+  if (type)
>+    set_mem_attributes (def, type, 1);
>   set_mem_align (def, align);
> 
>   /* If we're dropping a label to the constant pool, make sure we