From: Richard Sandiford <richard.sandiford@linaro.org>
To: gcc-patches@gcc.gnu.org
Subject: Don't query the frontend for unsupported types
Date: Wed, 20 Sep 2017 12:36:00 -0000 [thread overview]
Message-ID: <87shfhzgwc.fsf@linaro.org> (raw)
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?
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
next reply other threads:[~2017-09-20 12:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 12:36 Richard Sandiford [this message]
2017-09-20 15:05 ` Richard Biener
2017-09-21 12:56 ` Richard Sandiford
2017-09-21 15:03 ` Richard Biener
2017-09-22 16:43 ` Richard Sandiford
2017-09-25 12:54 ` Richard Biener
2017-10-01 16:17 ` Richard Sandiford
2017-10-23 18:14 ` Richard Sandiford
2017-10-25 13:56 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87shfhzgwc.fsf@linaro.org \
--to=richard.sandiford@linaro.org \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).