From patchwork Wed Sep 20 12:36:03 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 816183 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-462589-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="FfE+Fz3/"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3xxzkj2gLvz9s82 for ; Wed, 20 Sep 2017 22:36:28 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type; q=dns; s= default; b=ucOj0S2mRJ7tC44FWqXte4zIaqMJbpqI4ouwYkTCoVb7U6xa4p+Ju nqMgagBWvld8IAWldh+bJZ7DwVAMQRIdO4E1m8j0YZe5aTP6A4yqGQBEmyezQ1ga FLqMjXwW32GjKmGnMopCfiGQByAAx0Y+rq/e7GtLamGhaFaDIbrtb8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type; s= default; bh=m9wdc5f6s8GetE41gB7Ys6/A9Xc=; b=FfE+Fz3/WwtbDKN0kWF7 v/syA0vdIp1gnXj6K8uygQbjQyegNgeqprL2a4PfpLn7Z0jeG4T8ooWNwRKIpvAM S6hoFpOG/4HhSNTqrKL1bBDGhR//cYNssdIh6m7xUj/iM+oE9d8mJ4qydXfYSJNd 4kW3g+MEuP8UAb5I4XBBcnY= Received: (qmail 91309 invoked by alias); 20 Sep 2017 12:36:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 91170 invoked by uid 89); 20 Sep 2017 12:36:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.3 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3055 X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Sep 2017 12:36:11 +0000 Received: by mail-wm0-f42.google.com with SMTP id e71so6767891wmg.4 for ; Wed, 20 Sep 2017 05:36:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:subject:date:message-id :user-agent:mime-version; bh=xgDcsoWSey1meWipASykuVjMjS5F4IeIxU/IK8Qj17A=; b=Hj3z8AgAn2iu10WSvIh8RRFYmBFkD8TCbkK6kz2YUDeMaDA2JRaqj+ytkrefa5E2mc bQgUw7L7rwpDN5B0dUBAdlknVegcQSiFO/So4pcNabY3KAIt4gbnPNv1NEHZnsnAeJRY s3MqJkA+m1t791TO5IYlCQcPJhDu7RdqTMirdPx7Xth4uS9V98p9NMLxNAijWY7UnYXA I5F4vx4OzmyfV8UGo2C6ntuwxnYM8z0H+Wh/RYhQdt6KMsg/Or+THbZ7rjGsVs7E6gK9 PY7kz0+4vxIqnDjew0JOTjFcwpQWDKWhiLct0L3YRnpm1fSh9tr6+WjMX25kqvQ7MHKG hKEA== X-Gm-Message-State: AHPjjUigFvCxgWfmcKw24gLxOQoG+vKL1YSwT76xaco+g08SOeSQix8n OL+vlPFoJjtwtagLIPyruPGilnmOPJs= X-Google-Smtp-Source: AOwi7QAXT3P2Mz7Y3d85ZZv+o+LClfoRcDV17En8b5YYr+6JLURW7uiqQhKMcmWhbJb3DKU7b1L1HA== X-Received: by 10.28.131.13 with SMTP id f13mr4206614wmd.157.1505910969064; Wed, 20 Sep 2017 05:36:09 -0700 (PDT) Received: from localhost (92.40.248.127.threembb.co.uk. [92.40.248.127]) by smtp.gmail.com with ESMTPSA id f140sm1590786wmd.12.2017.09.20.05.36.07 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Sep 2017 05:36:08 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: Don't query the frontend for unsupported types Date: Wed, 20 Sep 2017 13:36:03 +0100 Message-ID: <87shfhzgwc.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 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 Alan Hayward David Sherwood 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 (); *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