From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id E17633888012 for ; Fri, 23 Jul 2021 06:50:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E17633888012 Received: by mail-ej1-x636.google.com with SMTP id v21so2265209ejg.1 for ; Thu, 22 Jul 2021 23:50:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xn1IvvewTcqJsB1fA6MA7qDbfffCvbpVI2JBl/SO4Iw=; b=eby6VcEKWWowXkAoOIVEvHOsEPK4HrA53XplWAhQPPtVX2tqjAJrBjyJxL/HDCS0oO KoKLzlrYhBF7AnVjob5GtW0iqkFztUe+SzQyDzuExFfe77LvX4rgWpJ/RhnM6C3SQnPT C4nAtzKLxeWTPOCVkwDnKvgHHz13HHXKyV5r3KMD+NUM/ObJ121nvWsvRIKqbRfdXHzY 04Ov7J/7O1WLR/6cKQG0v2jfkkGFrgZCfbgKaX0bOR8TpWBgm/kt5uGPozJcL0Ks7S2T uPeHny8xviRJgTxcNQ5YS/qkqWtmFBL+Zd0/C2FbZ5hfPXlmSnVNLl3xktYX/8QXuGs7 th0g== X-Gm-Message-State: AOAM530NQKrfvpTFFFZDtrs54eUSF048BV17GhaxgopR/4zkeg1DgZaG iLT+XWo5iO8rqk0mX78awLA+CaD7UccWUKVDUHy9wQoHjP0= X-Google-Smtp-Source: ABdhPJyMQUn4rtgAz9vYAp9K9kmi46wupA2pZsfA9i/OtTgmofNyfTqnsWwJUuC7SZ37dzSBzqvGGjbn3xXVXpRLAH4= X-Received: by 2002:a17:906:844:: with SMTP id f4mr3263387ejd.78.1627023034723; Thu, 22 Jul 2021 23:50:34 -0700 (PDT) MIME-Version: 1.0 References: <20210722235151.GO1583@gate.crashing.org> In-Reply-To: <20210722235151.GO1583@gate.crashing.org> From: "Bin.Cheng" Date: Fri, 23 Jul 2021 14:50:23 +0800 Message-ID: Subject: Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch To: Segher Boessenkool Cc: "bin.cheng" , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Fri, 23 Jul 2021 06:50:37 -0000 On Fri, Jul 23, 2021 at 7:53 AM Segher Boessenkool wrote: > > On Wed, Jul 14, 2021 at 05:14:16PM +0800, bin.cheng via Gcc-patches wrote= : > > Hi, > > I ran into a wrong code bug in code with deep template instantiation wh= en working on sdx::simd. > > The root cause as described in commit summary is we skip prologue insns= in init_alias_analysis. > > This simple patch fixes the issue, however, it's hard to reduce a case = because of heavy use of > > templates. > > > Subject: [PATCH 1/2] Don't skip prologue instructions as it could affec= t alias > > analysis > > > > In init_alias_analysis, we skip prologue instructions but this is > > wrong as it could affect base value analysis for registers as well > > as following analysis/transformations like cselib and dse: > > prologue: > > x12 =3D 0x1810 > > sp =3D sp - x12 > > ... > > ... > > x12 =3D SYMBOL_REF(.LC89) > > Here reg_base_value[12] is set to ".LC89", however this is only true > > after the second instruction setting x12. The patch fixes the issue > > by just handling prologue instructions as normal. Though ideally it > > can be improved in context-sensitive way. > > In what pass do you get the bad behaviour? dse2? postreload? Or what > else? Hi Segher, It is dse2 deleting non dead stores based on wrong cse info again based on wrong alias info. The code flow is quite tricky, given insn list like: x12 =3D 0x1810 sp =3D sp - x12 ... [sp + offset] =3D x y =3D [sp + offset] ... [sp + offset] =3D z ... x12 =3D SYMBOL_REF(.LC89) 1=E3=80=81alias computes wrong reg_base_value[12] =3D symbol_ref(.LC89) 2=E3=80=81when dse2 process "y =3D [sp + offset]", the calling sequence is = : scan_insn -> check_mem_read_rtx -> check_mem_read_rtx -> canon_true_dependence(group_id =3D=3D -1) -> true_dependence_1 which has below code: ------------------------------------------------------------------ base =3D find_base_term (x_addr); if (base && (GET_CODE (base) =3D=3D LABEL_REF || (GET_CODE (base) =3D=3D SYMBOL_REF && CONSTANT_POOL_ADDRESS_P (base)))) return 0; x_addr is "sp - x12", sp has no base term, however x12 has symbol_ref(.LC89) base term, and the code returns 0. As a result, dse2 considers storing x as dead when processing "[sp + offset] =3D z". Sorry I can't reproduce a case out of it. Thanks, bin > > Your patch looks correct, but I'd like to know why it has seemed to work > for so long :-) > > > Segher