From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 241A6385829E for ; Mon, 15 Aug 2022 07:46:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 241A6385829E Received: by mail-ed1-x52e.google.com with SMTP id r4so8591166edi.8 for ; Mon, 15 Aug 2022 00:46:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=UG2Jb/E0/AM0H3L6IvU4diewQ8Utr51XXalM6Xo2GYs=; b=wAsueNsRtE/jmpc8OYjbcGOM0s9RZnwk1HUadN3AUHfJVZ3DijEy2aFY4Uyhx4nNH+ hy9iGdAuFoBERBooAQz38QUjCx/GlBhrzDIda4xcRk4y4EN9o/5MdbTVndlFBa6te2Gz KnCEjwGAsQv17qxCtK5rYNw8L7dFzHfVnickIKHwMZuuv7WtVvdwh/uCAxmYH2NEiQtP /7Gli4rvmhjgDR7GmN69aKmmA+ZP2pRb/vrdtrMOmmti9O4DB05CTfOEaqJVnA7EwKwN zGea22XkdFGGRpJEUIT/3nC9pwWzoFFfnh127CQoQzdeWOiNkABmLs1VlvwZlbLJdCIc CIaw== X-Gm-Message-State: ACgBeo1SNPQT14H2BQBQBxkpyDg3yGFgYrFtbEHJsI83zffibOFJmKsn 1uYVV/qTbBOuHGajjLIIZq/4hF/AaRZjhNPRE2hErD5O X-Google-Smtp-Source: AA6agR7+9k+phFfRjldKm5rfj7Jq8KSQoEp1BwSykb6YnGEz1ARho6uYJpcctmOuSIN7YtopRW8RuwQJ3702SEF0fBA= X-Received: by 2002:a05:6402:500d:b0:440:9bc5:d0c1 with SMTP id p13-20020a056402500d00b004409bc5d0c1mr13705040eda.202.1660549563521; Mon, 15 Aug 2022 00:46:03 -0700 (PDT) MIME-Version: 1.0 References: <002201d8ae8b$d11fa9b0$735efd10$@nextmovesoftware.com> In-Reply-To: <002201d8ae8b$d11fa9b0$735efd10$@nextmovesoftware.com> From: Richard Biener Date: Mon, 15 Aug 2022 09:45:51 +0200 Message-ID: Subject: Re: [x86 PATCH] PR target/106577: force_reg may clobber operands during split. To: Roger Sayle Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 15 Aug 2022 07:46:07 -0000 On Fri, Aug 12, 2022 at 10:41 PM Roger Sayle wrote: > > > This patch fixes PR target/106577 which is a recent ICE on valid regression > caused by my introduction of a *testti_doubleword pre-reload splitter in > i386.md. During the split pass before reload, this converts the virtual > *testti_doubleword into an *andti3_doubleword and *cmpti_doubleword, > checking that any immediate operand is a valid "x86_64_hilo_general_operand" > and placing it into a TImode register using force_reg if it isn't. > > The unexpected behaviour (that caught me out) is that calling force_reg > may occasionally clobber the contents of the global operands array, or > more accurately recog_data.operand[0], which means that by the time > split_XXX calls gen_split_YYY the replacement insn's operands have been > corrupted. > > It's difficult to tell who (if anyone is at fault). The re-entrant > stack trace (for the attached PR) looks like: > > gen_split_203 (*testti_doubleword) calls > force_reg calls > emit_move_insn calls > emit_move_insn_1 calls > gen_movti calls > ix86_expand_move calls > ix86_convert_const_wide_int_to_broadcast calls > ix86_vector_duplicate_value calls > recog_memoized calls > recog. > > By far the simplest and possibly correct fix is rather than attempt > to push and pop recog_data, to simply (in pre-reload splits) save a > copy of any operands that will be needed after force_reg, and use > these copies afterwards. Many pre-reload splitters avoid this issue > using "[(clobber (const_int 0))]" and so avoid gen_split_YYY functions, > but in our case we still need to save a copy of operands[0] (even if we > call emit_insn or expand_* ourselves), so we might as well continue to > use the conveniently generated gen_split. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32}, > with no new failures. Ok for mainline? Why this obviously fixes the issue seen I wonder whether there's more of recog_data that might be used after control flow returns to recog_memoized and thus the fix would be there, not in any backend pattern triggering the issue like this? The "easiest" fix would maybe to add a in_recog flag and simply return FAIL from recog when recursing. Not sure what the effect on this particular pattern would be though? The better(?) fix might be to push/pop recog_data in 'recog', but of course give that recog_data is currently a global leakage in intermediate code can still happen. That said - does anybody know of similar fixes for this issue in other backends patterns? Thanks, Richard. > > > 2022-08-12 Roger Sayle > > gcc/ChangeLog > PR target/106577 > * config/i386/i386.md (*testti_doubleword): Preserve a copy of > operands[0], and move initialization of operands[2] later, as the > call to force_reg may clobber the contents of the operands array. > > gcc/testsuite/ChangeLog > PR target/106577 > * gcc.target/i386/pr106577.c: New test case. > > > Thanks, > Roger > -- >