From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 3152B3858D20 for ; Mon, 30 Oct 2023 20:55:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3152B3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3152B3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698699356; cv=none; b=x/mwtaU7hkxZwOXq6McYTj1z+CwzV1OwBF36Sc0+Hk4sQuz0hk9cXat84wgXsKd6xDuXpiXpdsuP+1rGdjqQagINeZqYhsDcDC5AuwXvetLRjD8GPd80as8QnyXEG1Nqk9rftoawT0rvaYypT18eQfo3xivyxoouCUeZHicPtqU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698699356; c=relaxed/simple; bh=B/EWC2HmFVp6cUWdeSzrCEVMaHqAE5hNFxrZAs7qMmI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=iSlswvRpv+PNn+9aj3Lv3R8XUghCmJFMdTNXhqu4hoYnhKwoP5A2cNe3w6dkzrOTK0iwv3xNKUzxixDa898K2IPcPZ9LPWgrcOEsMrPBjHNXDzoagTYd/bAxXLZPlN/CeJkHia2ScD6aYDqL1p/C9hKqBPE0dzLyYgzuw2QzXpk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1cc30bf9e22so18608915ad.1 for ; Mon, 30 Oct 2023 13:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698699353; x=1699304153; darn=gcc.gnu.org; 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=AqstaTS4kk7b4KGJfXlRTn5bzRYqpoKkiIib82Pq2Sw=; b=J1GpcgkIe4dhwWroxwGadUbPUuzOpbePegGVFXLa8Jfp1ZcCb25xFGuC6qJbyTuJLe EI88d75GNPw8r/p9tpndqqST/xbp+8f0BDXv30P5xDrsNshc3/JOmwWZ/W0uoNPbQjyn eI8QSqHl6KUjAWfT8AjLtsWaJU38wbAXOAhCuJArpMMAm8kg+w8z6BNWWp4m8iutOO7l lICXt5kzICJhmb4Fh5azppuekholazHFb6j6GWRE81ZjQebOOHxjvWEg38cKgOUKL4b+ T6zZ70ipxrrx70cY/3L8C7Eun+xnURy7/6pIU7YaznDe276SG3RlZy3wgHvaiyN8oYAt 3a4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698699353; x=1699304153; 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=AqstaTS4kk7b4KGJfXlRTn5bzRYqpoKkiIib82Pq2Sw=; b=L28+8qHFP+OL7TM9S/9gJpXFajx7bjvQYy3zedzyD9sTPRaniO7ptIETmLHXP4Gc1r o4EXmMWs/fD4Q+ENDM27o9aoo0PqEFwVhjw3eeuIJpy6UJIvQXM0gXzf7mbMTFw35w+f K6Umv5Cgn5lTwE4uVI9LKSouY6oWm545U7ef1MVnOfuQL7JOJQf2rV1xcoB75CvYw4Xi ArVanHN1P7V1kr3YGI8tc29ZoSA8w65wrwvotQfUE7lX6sO+CjYY7JqA2nsjGVTvuaoS VRtjbM+O9YHGkYsqoFVVMccn7nAzZgz7B2WHZ9pSWbEeuEU5IdDXUW42+RReXCJKrKz+ KOmA== X-Gm-Message-State: AOJu0YybSXiYhyzC/7DadfhAooowGswOU9UhkFssIZTXpZ8LcPxBYSA8 mVNZ6oNClzEhz06/Uc22z6IJbbXires= X-Google-Smtp-Source: AGHT+IHIuxKHBlFtQ7IV6+GpGdPvHs9o4Ko3aogybSPI0NDDvwyNk1NiAduXXOB5Pcsmdpf5qwrYjA== X-Received: by 2002:a17:902:e545:b0:1c9:ddd8:9950 with SMTP id n5-20020a170902e54500b001c9ddd89950mr854227plf.21.1698699352828; Mon, 30 Oct 2023 13:55:52 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id w17-20020a1709029a9100b001c73eace0fesm6614857plp.157.2023.10.30.13.55.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Oct 2023 13:55:52 -0700 (PDT) Message-ID: <3687a873-2b32-4bb4-9f42-d42b87619f43@gmail.com> Date: Mon, 30 Oct 2023 14:55:47 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] RISC-V: Support -mcmodel=large. Content-Language: en-US To: KuanLin Chen , gcc-patches@gcc.gnu.org Cc: Kito Cheng References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_BLACK autolearn=no 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 10/25/23 19:49, KuanLin Chen wrote: > This is a RFC patch for large code model implementation. > > gcc/ChangeLog: > * gcc/config/riscv/predicates.md(move_operand): Check SYMBOL_REF > and LABEL_REF type. > (call_insn_operand): Support for CM_Large. > (pcrel_symbol_operand): New. > * gcc/config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Add builtin_define > "__riscv_cmodel_large". > * gcc/config/riscv/riscv-opts.h (riscv_code_model): Define CM_LARGE. > * gcc/config/riscv/riscv-protos.h (riscv_symbol_type): Define > SYMBOL_FORCE_TO_MEM. > (riscv_asm_output_pool_epilogue): New. > * gcc/config/riscv/riscv.cc (riscv_classify_symbol) Support CM_LARGE model. > (riscv_symbol_insns) Add SYMBOL_FORCE_TO_MEM. > (riscv_cannot_force_const_mem): Ditto. > (riscv_split_symbol): Ditto. > (riscv_force_address): Check pseudo reg available before force_reg. > (riscv_size_ok_for_small_data_p): Disable in CM_LARGE model. > (riscv_can_use_per_function_literal_pools_p): New. > (riscv_asm_output_pool_epilogue): New. Hook ASM_OUTPUT_POOL_EPILOGUE. > (riscv_output_mi_thunk): Add riscv_in_thunk_func. > (riscv_option_override): Support CM_LARGE model. > (riscv_function_ok_for_sibcall): Disable sibcalls in CM_LARGE model. > * gcc/config/riscv/riscv.h (ASM_OUTPUT_POOL_EPILOGUE): Hookfg > * gcc/config/riscv/riscv.md (unspec): Define UNSPEC_FORCE_FOR_MEM. > (*large_load_address"): New. > * gcc/config/riscv/riscv.opt (code_model): New. > > gcc/testsuite/ChangeLog: > > * gcc/testsuite/gcc.target/riscv/large-model.c: New test. First, thank you so much for tackling this. It's one of the many missing components that we need to round out the implementation. > > > 0001-RISC-V-Support-mcmodel-large.patch > > From b09ba36220db1dbce3b1934685b1783125b5cb66 Mon Sep 17 00:00:00 2001 > From: Kuan-Lin Chen > Date: Sun, 18 Feb 2018 20:19:49 +0800 > Subject: [PATCH] RISC-V: Support -mcmodel=large. > > --- > gcc/config/riscv/predicates.md | 23 +++++- > gcc/config/riscv/riscv-c.cc | 4 + > gcc/config/riscv/riscv-opts.h | 1 + > gcc/config/riscv/riscv-protos.h | 4 +- > gcc/config/riscv/riscv.cc | 77 +++++++++++++++++++- > gcc/config/riscv/riscv.h | 2 + > gcc/config/riscv/riscv.md | 9 +++ > gcc/config/riscv/riscv.opt | 3 + > gcc/testsuite/gcc.target/riscv/large-model.c | 11 +++ > 9 files changed, 127 insertions(+), 7 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/riscv/large-model.c > > @@ -312,9 +313,15 @@ > }) > > (define_predicate "call_insn_operand" > - (ior (match_operand 0 "absolute_symbolic_operand") > - (match_operand 0 "plt_symbolic_operand") > - (match_operand 0 "register_operand"))) > + (match_operand 0 "general_operand") > +{ > + if (riscv_cmodel == CM_LARGE) > + return register_operand (op, mode); > + else > + return (absolute_symbolic_operand (op, mode) || > + plt_symbolic_operand (op, mode) || > + register_operand (op, mode)); > +}) Formatting nit. When wrapping a long line, bring the operator down to the next line, indented just beyond the open paren. Like this: return (absolute_symbolic_oeprand (op, mode) || plt_symbolic_operand (op, mode) || register_operand (op, mode); Also make sure to use a tab when indenting something 8 spaces. It's an annoyance, but it's the standard way things are formatted in GCC. THere are some scripts in the contrib subdirectory which can help find formatting problems, though I'm not sure they work on .md files. > @@ -1972,7 +1992,19 @@ static rtx > riscv_force_address (rtx x, machine_mode mode) > { > if (!riscv_legitimate_address_p (mode, x, false)) > - x = force_reg (Pmode, x); > + { > + if (can_create_pseudo_p ()) > + return force_reg (Pmode, x); Note that $ra is fixed now. So if you need a scratch register, you can fall back to $ra. More importantly, what are the circumstances where you can be asked to force an address after the register allocation/reloading phase is complete? Or does it happen within the register allocators (the latter would be an indicator we need a secondary reload). > @@ -5665,6 +5697,9 @@ riscv_size_ok_for_small_data_p (int size) > static bool > riscv_in_small_data_p (const_tree x) > { > + if (riscv_cmodel == CM_LARGE) > + return false; > + > if (TREE_CODE (x) == STRING_CST || TREE_CODE (x) == FUNCTION_DECL) > return false; How does large code model impact our ability to access small data through $gp? Aren't they independent? > +void > +riscv_asm_output_pool_epilogue (FILE *f, const char *, tree, > + HOST_WIDE_INT offset) > +{ > + /* When using per-function literal pools, we must ensure that any code > + section is aligned to the minimal instruction length, lest we get > + errors from the assembler re "unaligned instructions". */ > + if ((offset & 3) && riscv_can_use_per_function_literal_pools_p ()) > + ASM_OUTPUT_ALIGN (f, 2); > +} So the comment implies you're aligning the section. If that were the case, then why doesn't the function alignment come from FUNCTION_BOUNDARY when we first start emitting the function? Or is it the case that the comment is incorrect and you've actually got mixed code/rodata? > > +(define_insn "*large_load_address" > + [(set (match_operand:DI 0 "register_operand" "=r") > + (mem:DI (match_operand 1 "pcrel_symbol_operand" "")))] > + "TARGET_64BIT && riscv_cmodel == CM_LARGE" > + "ld\t%0,%1" > + [(set_attr "type" "load") > + (set (attr "length") (const_int 8))]) So it would seem like you're relying on the assembler to expand the ld? Is there any reasonable way to expose this properly to the compiler? I'd start by emitting the right instructions in the template. Once that's working, then we could look to split the components into distinct insns. I also worry that we've got a mem->reg move instruction that is not implemented in the standard movXX patterns. Traditionally that's been a recipe for problems. It was certainly a requirement for reload, but I don't know offhand if it's a hard requirement for LRA. Can you try to merge that in with the standard movdi pattern? Overall it looks pretty good. Does Andestech have a copyright assignment in place? Or are you contributing under the DCO rule? https://gcc.gnu.org/dco.html JeJeff