From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91398 invoked by alias); 24 May 2017 08:31:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 90287 invoked by uid 89); 24 May 2017 08:31:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.5 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= X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 May 2017 08:31:51 +0000 Received: by mail-wm0-f44.google.com with SMTP id b84so55334623wmh.0 for ; Wed, 24 May 2017 01:31:54 -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=Lqi/NEijo9UY7VsSiFAHXMC0ov0fd0dM++JESjMjjVM=; b=tR9m+z0FtieYr5FSQenL6CPxHYCVZRietOKvlvUKu8Ifx7+v0nW3EcGmlfrskwBVVB Mwe8/smqUdhCA46FQ4mui1vQNiOfw8lBiWRKt4GkHJXaXawv0LvwnkWSlPRmGcNokIRF LV4Q7vh4mqEDt4Uatlu5U0XGXLduh9TJQMpbZGe5evvjLjLEblPR/kWx5DKRvO8BvTpj hZme83XIE4/DKk4GZwQOKWTNUUxhStFeOQA+vNAhJZ6mjFlupIZ6kJxepQchsIKACaKq hKJVX9vMLFTAkUrHySgmseO/wJdMWqcHlQRWbB1HOGKsqWZE1SKsc8O4GVEKSYoSAarr G8Mg== X-Gm-Message-State: AODbwcA4/Lci3WyHzh2aQiPzJVuT1GypPVzGyJK2A0cs46ekh959+fNz 7+5otQlgmHoyGXZKxkmwFA== X-Received: by 10.223.160.148 with SMTP id m20mr18184221wrm.176.1495614712395; Wed, 24 May 2017 01:31:52 -0700 (PDT) Received: from localhost (188.29.164.253.threembb.co.uk. [188.29.164.253]) by smtp.gmail.com with ESMTPSA id x17sm1987029wrd.63.2017.05.24.01.31.51 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 May 2017 01:31:51 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: Fix pessimistic DImode handling in combine.c:make_field_assignment Date: Wed, 24 May 2017 08:44:00 -0000 Message-ID: <87efvezmdl.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-05/txt/msg01835.txt.bz2 The make_field_assignment code: src = force_to_mode (src, mode, GET_MODE_PRECISION (mode) >= HOST_BITS_PER_WIDE_INT ? HOST_WIDE_INT_M1U : (HOST_WIDE_INT_1U << len) - 1, 0); would ignore the field length len for DImode, even though DImode can be handled using HWIs. I think the code should be testing len instead. The patch was originally part of the SVE machine_mode series. Retesting showed that it changed the asm output on powerpc for a few tests, so I thought it should go in separately. Each test change seemed to be an improvement. Tested on aarch64-linux-gnu and x86_64-linux-gnu. I no longer have access to the compile farm to test on the powerpc boxes there. Thanks, Richard 2017-05-24 Richard Sandiford gcc/ * combine.c (make_field_assignment): Check len rather than the mode precision when calling force_to_mode. Index: gcc/combine.c =================================================================== --- gcc/combine.c 2017-05-03 08:46:32.777861592 +0100 +++ gcc/combine.c 2017-05-24 09:25:25.170351268 +0100 @@ -9634,7 +9634,7 @@ make_field_assignment (rtx x) other, pos), dest); src = force_to_mode (src, mode, - GET_MODE_PRECISION (mode) >= HOST_BITS_PER_WIDE_INT + len >= HOST_BITS_PER_WIDE_INT ? HOST_WIDE_INT_M1U : (HOST_WIDE_INT_1U << len) - 1, 0);