From patchwork Tue Jan 16 16:14:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 124738 Delivered-To: patch@linaro.org Received: by 10.46.64.148 with SMTP id r20csp1066188lje; Tue, 16 Jan 2018 08:15:10 -0800 (PST) X-Google-Smtp-Source: ACJfBoskZHUs6ui+CEwtKIGsod412OkR4qK/Ap8kZXPhTcY6LOvbP9F8Q1Zkthw1++JV36SVapw0 X-Received: by 10.124.22.129 with SMTP id v1mr32923252ply.170.1516119310256; Tue, 16 Jan 2018 08:15:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516119310; cv=none; d=google.com; s=arc-20160816; b=SjDXR1+Z/WS3V/gs2u4dP2BEgKNN/wR/BOGALXTSEIoJzgultzPO2Ex38+UIMuBdT9 v0N9VnvDyiUkJKHZAFSFwp4L/Vf/+1BU/M/DRLkXm4fZAPX62xoPuqcQZcwEAv0RGHZk d8jHuyj9PANiGWLoeRxlBTCGgClzmqoZutyKUNqnWjYvOp0rwRng9+9Kxq7Gs/QBYvo/ YJMZHvjheOqq2pTNkwDd4MWvfLnK8JtmbZv3uu0NMUFBSnXyh3ijxU1A0kJTG94LEIQw EW665tTRWq3hblXlVF2XzggIl/zx7a5jEtG5rRtwCq9IbiQI36LvMk5k0EWQ67wDfCZo 97ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:message-id:date:subject:mail-followup-to:to :from:delivered-to:sender:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:mailing-list:dkim-signature :domainkey-signature:arc-authentication-results; bh=UhQRHc4hG0JaFZqN6LFalkWl0CjHrJAY5xOEXc6kZqg=; b=EP60ywUn9o/MonTRcxitC05TzsRJSxBMk3z24b8o8Og5/awS/2M4pYk7T2ZB9WedOI KoWhPHXCKjspG67Qa21SemneAtau62XtGa/6hdrUFQ89RzKAJO1lzzOyCxfXZJvIu9dS SqG+z6d7J93ZdHZFMBpint6DL5EdIapU2+5C1/rnxL3FbpZ70vrSEuVDrVYKPP7jtZ3p kec7AzKYf355miJLwpA6zUZNEFoQdyXApwOtyU4VAP4IP11hICuy8jY2cqimM9k2TxKF Im5qq+wjKcS9IP5rKf40rohG4dOMnqsuRpGifVRJMH0P+djDvIs5PKFnkp9q1MAx/bFs tNdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=efeVMNBW; spf=pass (google.com: domain of gcc-patches-return-471389-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-471389-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id z33si2175658plb.613.2018.01.16.08.15.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 08:15:10 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-471389-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=efeVMNBW; spf=pass (google.com: domain of gcc-patches-return-471389-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-471389-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org 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=w+K+hGKES+4y1a2agQnserBHXXuPlrckiLKcoLFwgMRijAuZF229b edpq8efkp2OrLsB9sf5arPG6v2Bz0+ubFV7kgn4Uq6zJP8wG8lQO7uKKd5/O3lKM oQQZjA9PSnmKpRBDtfbmVRYtv/i0VFxwGXQSLNr73d1+6gY4gKAJWw= 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=JErZWUlZX1AIj6en0jfgJ/T6Bdw=; b=efeVMNBW4ZKTgoNt2qWY lHDtWF3InhNIwtWUwElmlrNGZ+EQeukH0qoUEh/5pfSk6HGqVzQ4bw2iUtZWLLgS PeaIOz6+Cmig59scLyuiwbSB5evwodIpXskWbzOIsZ2Lsg+3bIAs6krDWJnBg3r0 4bobZ5iqgNdO8fnozp7U2II= Received: (qmail 101808 invoked by alias); 16 Jan 2018 16:14:58 -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 101793 invoked by uid 89); 16 Jan 2018 16:14:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=honour, HX-Received:10.28.218.207 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; Tue, 16 Jan 2018 16:14:54 +0000 Received: by mail-wm0-f42.google.com with SMTP id v71so9788431wmv.2 for ; Tue, 16 Jan 2018 08:14:54 -0800 (PST) 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=UhQRHc4hG0JaFZqN6LFalkWl0CjHrJAY5xOEXc6kZqg=; b=EAdwEMMr0md0Lblz974a29e0dzVRquuOkpJMH/amsuRF0192vO7cC50orxKaIumcaF tiquGfOdJcwm8tyYk/15wG5Gz+n7KOJsXHii0cUi48j0Uhxi9KuuT9g8isqjy6R0Ip5O Hizpg+80V5DQdfkLItyZewG6BkU6jgIrJ7grPD8WhVs99sAGyVbLNy1iY3uXUyzppBD5 a/X29M5LxsvoDL/euGuiYxBRkAkP/vaFM+bML2qakTSIv7ldLJojJMvdjKsUO2jHvQkV Dk1e3sJn71FwTVdY2Mjcwsj1CwZcBnpdGu9r5z047o+FnLFF69XRn2v5sIMl5r/eW6+T jSPg== X-Gm-Message-State: AKwxytcWn7IUxf46Q37uvvHIPwW7+KOCSWSdvy5jUj88K5SdXFXKsIc1 coZwszNr2QK4nM//QKmMdFNYgmCdhEA= X-Received: by 10.28.218.207 with SMTP id r198mr7901216wmg.138.1516119292409; Tue, 16 Jan 2018 08:14:52 -0800 (PST) Received: from localhost ([95.144.14.233]) by smtp.gmail.com with ESMTPSA id c11sm3539866wrc.8.2018.01.16.08.14.50 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Jan 2018 08:14:51 -0800 (PST) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: VIEW_CONVERT_EXPR slots for strict-align targets (PR 83884) Date: Tue, 16 Jan 2018 16:14:50 +0000 Message-ID: <87vag1wzk5.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 This PR is about a case in which we VIEW_CONVERT a variable-sized unaligned record: unit-size align:8 ...> to an aligned 32-bit integer. The strict-alignment handling of this case creates an aligned temporary slot, moves the operand into the slot in the operand's original mode, then accesses the slot in the more-aligned result mode. Previously the size of the temporary slot was calculated using: HOST_WIDE_INT temp_size = MAX (int_size_in_bytes (inner_type), (HOST_WIDE_INT) GET_MODE_SIZE (mode)); int_size_in_bytes would return -1 for the variable-length type, so we'd use the size of the result mode for the slot. r256152 replaced int_size_in_bytes with tree_to_poly_uint64, which triggered an ICE. I'd assumed that variable-length types couldn't occur here, since it seems strange to view-convert a variable-length type to a fixed-length one. It also seemed strange that (with the old code) we'd ignore the size of the operand if it was a variable V but honour it if it was a constant C, even though it's presumably possible for V to equal that C at runtime. If op0 has BLKmode we do a block copy of GET_MODE_SIZE (mode) bytes and then convert the slot to "mode": poly_uint64 mode_size = GET_MODE_SIZE (mode); ... if (GET_MODE (op0) == BLKmode) { rtx size_rtx = gen_int_mode (mode_size, Pmode); emit_block_move (new_with_op0_mode, op0, size_rtx, (modifier == EXPAND_STACK_PARM ? BLOCK_OP_CALL_PARM : BLOCK_OP_NORMAL)); } else ... op0 = new_rtx; } } op0 = adjust_address (op0, mode, 0); so I think in that case just the size of "mode" is enough, even if op0 is a fixed-size type. For non-BLKmode op0 we first move in op0's mode and then convert the slot to "mode": emit_move_insn (new_with_op0_mode, op0); op0 = new_rtx; } } op0 = adjust_address (op0, mode, 0); so I think we want the maximum of the two mode sizes in that case (assuming they can be different sizes). But is this VIEW_CONVERT_EXPR really valid? Maybe this is just papering over a deeper issue. There again, the MAX in the old code was presumably there because the sizes can be different... Richard 2018-01-16 Richard Sandiford gcc/ PR middle-end/83884 * expr.c (expand_expr_real_1): Use the size of GET_MODE (op0) rather than the size of inner_type to determine the stack slot size when handling VIEW_CONVERT_EXPRs on strict-alignment targets. Index: gcc/expr.c =================================================================== --- gcc/expr.c 2018-01-14 08:42:44.497155977 +0000 +++ gcc/expr.c 2018-01-16 16:07:22.737883774 +0000 @@ -11145,11 +11145,11 @@ expand_expr_real_1 (tree exp, rtx target } else if (STRICT_ALIGNMENT) { - tree inner_type = TREE_TYPE (treeop0); poly_uint64 mode_size = GET_MODE_SIZE (mode); - poly_uint64 op0_size - = tree_to_poly_uint64 (TYPE_SIZE_UNIT (inner_type)); - poly_int64 temp_size = upper_bound (op0_size, mode_size); + poly_uint64 temp_size = mode_size; + if (GET_MODE (op0) != BLKmode) + temp_size = upper_bound (temp_size, + GET_MODE_SIZE (GET_MODE (op0))); rtx new_rtx = assign_stack_temp_for_type (mode, temp_size, type); rtx new_with_op0_mode