From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resdmta-c1p-023854.sys.comcast.net (resdmta-c1p-023854.sys.comcast.net [IPv6:2001:558:fd00:56::d]) by sourceware.org (Postfix) with ESMTPS id 27FEF3856944 for ; Tue, 15 Aug 2023 12:49:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 27FEF3856944 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=comcast.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=comcast.net Received: from resomta-c1p-022592.sys.comcast.net ([96.102.18.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resdmta-c1p-023854.sys.comcast.net with ESMTP id VsDeqWgsU5fwRVtToqQ1Jp; Tue, 15 Aug 2023 12:49:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1692103740; bh=V+fzK+JcW2xZOQN0/Iw5w27PK7eTkqRmdvhSpkqOkSw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=hYgnR8ZFfDziSwnKSOAh7e6+qTJbGwXLMVZbq8yEvkyNfMysgujeyEG+vudKj4Li1 cL0sEseQECkPCB3ZmjSU0pGLlZkCTkrU3v+KjfWDmiclyfoaps3N/uUHAv3BKHOYmA Y05bo3Dgi7RCwI4bjZ4ld6LWF2or77zZC68e9Fh7584VMx7YILMMC0u9QkONmhtdU9 h99WjdGwzwQrBh3X09L0uxa+djZwMKFP18ecm9GBGdUHUH4W/FZVLdpbkB7ZbiJpuI OwGXDbf41Z5PDOGvQkvWXvjpHCTi444tXNYZmP+vRpDdhMxB7aI7FyD5otCvAS1LZu bXHRj2+cFjbQA== Received: from smtpclient.apple ([73.60.223.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-c1p-022592.sys.comcast.net with ESMTPSA id VtTmqoaWMd3UqVtTnqqmoN; Tue, 15 Aug 2023 12:49:00 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: Porting to a custom ISA From: Paul Koning In-Reply-To: Date: Tue, 15 Aug 2023 08:48:58 -0400 Cc: MegaIng , gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Biener X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > On Aug 15, 2023, at 8:06 AM, Richard Biener via Gcc = wrote: >=20 > On Tue, Aug 15, 2023 at 1:38=E2=80=AFPM MegaIng via Gcc = wrote: >> ... >> And a bit more concrete with something I am having a hard time >> debugging. I am getting errors `invalid_void`, seemingly triggered by = an >> absent of `gen_return` when compiling with anything higher than -O0. = How >> do I correctly provide an implementation for that? Or disable it's >> usage? Our epilogue is non-trivial, and it doesn't look like the = other >> backends use something like `(define_insn "return" ...)`. >=20 > Somebody else has to answer this. Again using pdp11 as an example -- it doesn't define any of the *return = patterns either. Instead it has a define_expand "epilogue" which calls = a function to generate all the necessary elements, the last of which is = a machine-specific pattern that will produce the final return = instruction. =20 This is using the RTL flavor of prologue/epilogue. At one point in the = past that target directly emitted the assembly code for those, which = isn't the recommended approach. I tried the RTL flavor and found it to = be a better answer, and it certainly works for all the optimization = levels. paul