From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id 8A6B0385842C for ; Tue, 15 Aug 2023 13:26:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8A6B0385842C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2680eee423aso2863215a91.2 for ; Tue, 15 Aug 2023 06:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692105981; x=1692710781; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=DAS1or3+vprgzfeL3Q55NUEd6cFH5gmECieUDqQi86o=; b=RuB2MKvv57YKJ2urH/Lf/qqdDYqHfHiw9dwe/PnIma+cYU9foTOQUrKE9+/V/iSve9 5+bZORCTn8Ue1ZGG3b95VjVNqBUN/L2ICXi5xjzrZ34WKnb6Y5xifiQ5N5lJGWEYE0YQ TszUvSe8dMtZT7Jc45Kab+7yYz2yqibof7GSgWlkwkIgiPKtFHsIOKjWuN4Dm486KLAA PSrgCpbrL1pGdn265s0h55MGIp4aPxOgNqYZkM0+HmmuqHnl9k0tq8rcBvfh4xplik4d icIYyMgr0HUi6XupPVDAhvQLjYIa2x1S+jg+LUB8kX8te+6gRrPJVNv6fflCN5mN18Hp RUnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692105981; x=1692710781; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DAS1or3+vprgzfeL3Q55NUEd6cFH5gmECieUDqQi86o=; b=CtAGQwgrroXTsT9UHOdsMdWmT5BSU42FJciIe/ktB5zBI9WjlJjrfyIRH/iuInRLUM EUruxNWLQczfvhXMMyvZCfkR63Uxb4gqTTfYgutimEFLNLHWjOK0gn9M6Lbt+7XpHSN7 JkpWpOlYa18ZftIZjl0QmN+BRBYcYBTifQcRbpOR8YzwIitvjRZsNe/yjLdu5fwcNsBN 7AK4ucl3+Lp30779AGe4D0F+qXveUhUZnNEB3Ksn0GOCt1CwEtdpsGcVOmEh+pnqmvhX 9rPuBDXP0vdivn1gyFssPMRO2j/T26yg/eNtBLii5q9n2zN8P6zneV+vkBiAv7Csr86Z nmZw== X-Gm-Message-State: AOJu0YynYNHIj9PABByDz4gx4xvfpaUrE0Nv2bRCDWDKXFHrv3sxGw8v Udls2sf/U1PhalLI67b43Kk= X-Google-Smtp-Source: AGHT+IGMEfuwQmyGxhLd3VGEe6kgc3JvRELKC9+qRBTKjJEzNa6lsd3INWZbMfn4XvuWbrhhG10vfA== X-Received: by 2002:a17:90a:6046:b0:268:b682:23da with SMTP id h6-20020a17090a604600b00268b68223damr9005287pjm.34.1692105981246; Tue, 15 Aug 2023 06:26:21 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id 6-20020a17090a1a0600b00262eb0d141esm10293341pjk.28.2023.08.15.06.26.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Aug 2023 06:26:20 -0700 (PDT) Message-ID: <149433dc-de3c-9279-5585-e787ca8af853@gmail.com> Date: Tue, 15 Aug 2023 07:26:19 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Porting to a custom ISA Content-Language: en-US To: MegaIng , gcc@gcc.gnu.org References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 8/15/23 05:37, MegaIng via Gcc wrote: > One of the big challenges I am facing is that for our backend we > sometimes support 16bit as the max size a CPU supports, including for > pointers, and sometimes 32bit or 64bit. Am I seeing it correctly that > POINTER_SIZE has to be a compile time constant and can therefore not > easily be changed by the backend during compilation based on command > line arguments? We've certainly got targets which change POINTER_SIZE based on flags. It just needs to be a C expession. So you might see something like #define POINTER_SIZE (TARGET_SOMEFLAG ? 16 : 32) > > Also, on another backend I saw comments relating to libgcc (or newlib?) > not working that well on systems where int is 16bit. Is that still true, > and what is the best workaround? GCC has supported 16 bit targets for eons, there are still some in the tree. libgcc and newlib also support 16 bit targets. It can be difficult to support something like double precision floating point on a 16 bit target. So some 16 bit ports only support single precision floating point. > > 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" ...)`. Many ports define trivial returns. But it's much more common to need a prologue and epilogue. Those are typically define_expands which generate all the code to set up a stack frame and tear a stack frame down+return. Jeff