From patchwork Thu Jul 29 23:24:10 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 1511470 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4GbRSj1mCDz9sX1 for ; Fri, 30 Jul 2021 09:24:36 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 84CEB383B808 for ; Thu, 29 Jul 2021 23:24:34 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from arjuna.pair.com (arjuna.pair.com [209.68.5.131]) by sourceware.org (Postfix) with ESMTPS id 6858C385742F for ; Thu, 29 Jul 2021 23:24:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6858C385742F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bitrange.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bitrange.com Received: by arjuna.pair.com (Postfix, from userid 3006) id 325318A54E; Thu, 29 Jul 2021 19:24:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id 3193E8A4FA for ; Thu, 29 Jul 2021 19:24:10 -0400 (EDT) Date: Thu, 29 Jul 2021 19:24:10 -0400 (EDT) From: Hans-Peter Nilsson X-X-Sender: hp@arjuna.pair.com To: gcc-patches@gcc.gnu.org Subject: Committed: Fix MMIX breakage; ICE in df_ref_record, at df-scan.c:2598 Message-ID: User-Agent: Alpine 2.20.16 (BSF 172 2016-09-29) MIME-Version: 1.0 X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_NUMSUBJECT, 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: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" This bug made me dive into some of the murkier waters of gcc, namely the source of operand 2 to the "call" pattern. It can be pretty poisonous, but is unused (either directly or later) by most targets. The target function_arg (and function_incoming_arg), can unless specially handled, cause a VOIDmode reg RTX to be generated, for the function arguments end-marker. This is then passed on by expand_call to the target "call" pattern, as operand[2] (which is wrongly documented or wrongly implemented, see comment in mmix.c) but unused by most targets that do not handle it specially, as in operand 2 not making it into the insn generated for the "call" (et al) patterns. Of course, the MMIX port stands out here: the RTX makes it into the generated RTX but is then actually unused and is just a placeholder; see mmix_print_operand 'p'. Anyway, df-scan inspects the emitted call rtx and horks on the void-mode RTX (actually: that it represents a zero-sized register range) from r12-1702. While I could replace or remove the emitted unused call insn operand, that would still leave unusable rtx to future users of function_arg actually looking for next_arg_reg. Better replace VOIDmode with DImode here; that's the "natural" mode of MMIX registers. (As a future improvement, I'll also remove the placeholder argument and replace the intended user; the print_operand output modifier 'p' modifier (as in "PUSHJ $%p2,%0") with some punctuation, perhaps '!' (as in "PUSHJ $%!,%0"). I inspected all ports, but other targets emit a special function_arg_info::end_marker cookie or just don't emit "call" operand[2] (etc) in the expanded "call" pattern. gcc: * config/mmix/mmix.c (mmix_function_arg_1): Avoid generating a VOIDmode register for e.g the function_arg_info::end_marker. --- gcc/config/mmix/mmix.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/gcc/config/mmix/mmix.c b/gcc/config/mmix/mmix.c index 40bfb4314ddd..db7af7b75b6d 100644 --- a/gcc/config/mmix/mmix.c +++ b/gcc/config/mmix/mmix.c @@ -667,10 +667,17 @@ mmix_function_arg_1 (const cumulative_args_t argsp_v, { CUMULATIVE_ARGS *argsp = get_cumulative_args (argsp_v); + /* The mode of the argument will be VOIDmode for the "end_marker". Make sure + we don't ever generate a VOIDmode register; later passes will barf on that. + We may want to use the register number, so return something nominally + useful. Thus, for VOIDmode, use DImode, being the natural mode for the + register. */ + machine_mode mode = arg.mode == VOIDmode ? DImode : arg.mode; + /* Last-argument marker. */ if (arg.end_marker_p ()) return (argsp->regs < MMIX_MAX_ARGS_IN_REGS) - ? gen_rtx_REG (arg.mode, + ? gen_rtx_REG (mode, (incoming ? MMIX_FIRST_INCOMING_ARG_REGNUM : MMIX_FIRST_ARG_REGNUM) + argsp->regs) @@ -678,10 +685,10 @@ mmix_function_arg_1 (const cumulative_args_t argsp_v, return (argsp->regs < MMIX_MAX_ARGS_IN_REGS && !targetm.calls.must_pass_in_stack (arg) - && (GET_MODE_BITSIZE (arg.mode) <= 64 + && (GET_MODE_BITSIZE (mode) <= 64 || argsp->lib || TARGET_LIBFUNC)) - ? gen_rtx_REG (arg.mode, + ? gen_rtx_REG (mode, (incoming ? MMIX_FIRST_INCOMING_ARG_REGNUM : MMIX_FIRST_ARG_REGNUM)