From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 803573858412 for ; Thu, 14 Oct 2021 23:54:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 803573858412 Received: by mail-pf1-x436.google.com with SMTP id g14so6878890pfm.1 for ; Thu, 14 Oct 2021 16:54:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6KELa01zh8nFe/wrHZpB/slCV9PElse3TwvMlsOo4uE=; b=3udomIA/Kmx49UQ4nd4CKSoao2Ql+T1jf0M30AKSPvDXvEP2wmHpG29xN65MOdI4E2 HjyxhED/3q/v4KeUEI/Z9ppDVYCszDDd33+OJw59pvgiMA3jrZh3cc6F7rVVn5Z7c0cp dl9uRQU+MQeU356o22DzhqxAHG+fvJjwVOOtqiI7xf4AafHuTCmlqqg2qWbBXhRFuWq/ +ckIeCh1Bw9BiSjqipJRdcgskHPIkFxIrtyZEQWubAz0dk3w5GUVjqxXIDG38s3Etd+F gBXd8Dlhzx5fDCEDfZszU0rJes1gzbGLw2GdLklKW8Nro2w1CMYIZbDkf68WTjTfV1me CqQQ== X-Gm-Message-State: AOAM533HtpGAKE1PpvjQORR/esLBRjsTQpq4qIi+vn9Aw8jok6L3XSnx AzyqB6wQbQMQAEN+iarEaAGTmwV2fos= X-Google-Smtp-Source: ABdhPJz+IHc13/fJ+aUX0/+YXn4ewfxtKMG2VPQAx+rGimHe66Db0Kx7q3HBOIazMDc4MLt1SCMUmQ== X-Received: by 2002:a63:7542:: with SMTP id f2mr6566676pgn.64.1634255690316; Thu, 14 Oct 2021 16:54:50 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id u74sm3373373pfc.87.2021.10.14.16.54.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Oct 2021 16:54:50 -0700 (PDT) Subject: Re: [PATCH] middle-end/102682 - avoid invalid subreg on the LHS To: Richard Biener , gcc-patches@gcc.gnu.org References: <9n921r2-n5ss-r64o-o4qr-7s7696r591sp@fhfr.qr> From: Jeff Law Message-ID: <535ed781-7034-549a-8af7-c8268b292990@gmail.com> Date: Thu, 14 Oct 2021 17:54:49 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <9n921r2-n5ss-r64o-o4qr-7s7696r591sp@fhfr.qr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 23:54:53 -0000 On 10/11/2021 7:39 AM, Richard Biener wrote: > The following avoids generating > > (insn 6 5 7 2 (set (subreg:OI (concatn/v:TI [ > (reg:DI 92 [ buffer ]) > (reg:DI 93 [ buffer+8 ]) > ]) 0) > (subreg:OI (reg/v:V8SI 85 [ __x ]) 0)) "t.ii":76:21 74 {*movoi_internal_avx} > (nil)) > > via store_bit_field_1 when we try to store excess data into > a register allocated temporary. The case was supposed to > > /* Use the subreg machinery either to narrow OP0 to the required > words... > > but the check ensured only an register-aligned but not a large > enough piece. The following adds such missed check which ends up > decomposing the set to > > (insn 6 5 7 (set (subreg:DI (reg/v:TI 84 [ buffer ]) 0) > (subreg:DI (reg/v:V8SI 85 [ __x ]) 0)) "t.ii":76:21 -1 > (nil)) > > (insn 7 6 0 (set (subreg:DI (reg/v:TI 84 [ buffer ]) 8) > (subreg:DI (reg/v:V8SI 85 [ __x ]) 8)) "t.ii":76:21 -1 > (nil)) > > > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk? > > Thanks, > Richard. > > 2021-10-11 Richard Biener > > PR middle-end/102682 > * expmed.c (store_bit_field_1): Ensure a LHS subreg would > not create a paradoxical subreg. OK. Jeff