From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 77C103858D32 for ; Thu, 25 May 2023 13:55:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 77C103858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-64d41763796so1627976b3a.2 for ; Thu, 25 May 2023 06:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1685022917; x=1687614917; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0u/8N1vQVe2pvFXW25Ayorb+ru3QhywJUsC9boVYYgw=; b=WO/ccA8ny0PBrjEI2n44slJKjGCJtVeZXVH4fOp+EquZijjo7YX02955BeXRe1HKb/ rw+oa5iEZWeEVWaGoB40JJHxfCbWWoXkfhl38gPfrnUU5PYL3G0dBvNtaa4f9y2G7Hat ZyLy6ShgbPKW1FEb+bh3wvXTRHIJcUycC0oK8skqWS3WSgrEfbxmKLy69DM+VOHTEaxo gqPp8O3GNj8VN+xr6ju5oqGH1s2wYqwO2jeUyXxZ44EZEA1GzvPOj/uwAvCx7E6ypseI 0/FYueBA+FIddZcenxnpVnZF1B1kvYi0F4hfqZOZ02VKs0+EHsF/293xqHzCD+j0+dY/ y4fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685022917; x=1687614917; h=content-transfer-encoding:in-reply-to:from:references:cc: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=0u/8N1vQVe2pvFXW25Ayorb+ru3QhywJUsC9boVYYgw=; b=XBr794CZ675SqNDH6NjqXucTi2f2Cz1Q+GxjB8alX0WfzYwTYQa1ZNOlFbvxQLl3vj tmalXe4L4Ctx7okkQl1u4pu/H/VHcZaVtGvHPhr2WRWtbSSouRCleWg9i0xPFdwbtsEh yb7vMHJimDqMQOn1xYKR1kzkeV3Oeub4XYk2wRSHUfaXoxXfo/RblPaJxnSIksi+0TaD WzvReuRXwtU5dhMmP1k87CfuWtdnj8f81MnZi5YG+ak/jbPrvPzXb8kPmS5jV/xdteOg zzO6ZPRC+jkdslTQH8YjpbRMesRs1L7ifclaDh4BFnlQ0Dk3nqNQrpMuSanIjvWvu3gg 4CKg== X-Gm-Message-State: AC+VfDwiaxgZtvYViCXndPS49rixs4ERQ1fOvZD6ZhGf+V/4UKNVpMkL KyXkeLEkS6jtFiGpV05SkJ8zLp73/7JifGGfG9Y= X-Google-Smtp-Source: ACHHUZ72c0aMh8/67VTSo8pyA7hrKF9JCDT1aoVNCBfehAsJEsf8JKVJ/kp5MdNgfxT7xR/LPgjycQ== X-Received: by 2002:a05:6a00:13a4:b0:643:b27f:6c43 with SMTP id t36-20020a056a0013a400b00643b27f6c43mr9113180pfg.27.1685022917477; Thu, 25 May 2023 06:55:17 -0700 (PDT) Received: from ?IPV6:2601:681:8d00:265::f0a? ([2601:681:8d00:265::f0a]) by smtp.gmail.com with ESMTPSA id r14-20020a62e40e000000b0064cb6206463sm1228013pfh.85.2023.05.25.06.55.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 May 2023 06:55:17 -0700 (PDT) Message-ID: <07ba448b-d3f5-37be-8715-0c38554112a4@ventanamicro.com> Date: Thu, 25 May 2023 07:55:15 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: RISC-V Bootstrap problems Content-Language: en-US To: "juzhe.zhong@rivai.ai" , "kito.cheng" Cc: jeffreyalaw , palmer , vineetg , "Kito.cheng" , gcc-patches , Patrick O'Neill , macro References: <66780d8b-41bf-95ac-3266-c4025636757e@gmail.com> <8E35CC71575965B0+20230525121910161040251@rivai.ai> From: Jeff Law In-Reply-To: <8E35CC71575965B0+20230525121910161040251@rivai.ai> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 List-Id: On 5/24/23 22:19, juzhe.zhong@rivai.ai wrote: > >> It's highly unlikely we'll switch from the mechanisms we're using. >>>They're pretty deeply embedded into how all the ports are developed and >>>work. > > We just take a look at the build file. It seems that the functions > generated by define_insn > are so many. Do we have the chance optimize it? > I believe the tablegen mechanism in LLVM is well optimized in case of > generated files and functions > so that they won't be affected to much as instructions go up. Any define_insn or define_expand with a name that does not begin with a '*' will result in a function in insn-emit. Those functions allow us to generate those patterns either from generic parts of the compiler or from within the target. So if I have (define_insn "fubar" ...) I can say rtx x = gen_fubar (...); To constuct RTL matching the pattern for "fubar". So if there are patterns with names that are not used in this way, you can prefix their name with '*' to suppress creation of the generator function. I have not looked to see if this would help our situation. jeff