From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 4432D3846411 for ; Wed, 24 Feb 2021 21:40:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4432D3846411 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jimw@sifive.com Received: by mail-ej1-x629.google.com with SMTP id r17so5399640ejy.13 for ; Wed, 24 Feb 2021 13:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UYZIsh0NrSOQDrd1JqthCzGP2fby/uTg5ByP/XdrwnY=; b=gnrTo3+aWtw3rG4r6zopjBJ0EwserWNFK28basKuSIYi16nLG7wi9PwafWEMljXIsV Fu3j/cGEtQRE5gat9TC0Q/Zp8Zjk/REYT5Hv0OPwDa5pcUIGcTWfnpEYZbauJADYaEpj dlqXKvlRrH+zdY442+OAGTpCCZi9zyc4Ou8W9k4fcfl/kT2QbFPrabfTmF2Xph+npnD7 B7NA6rleQ6LinzM/T1bLZipo/KHPqPvDBwRG3JpAugq/Sr8r0oy/chGMsXyCkbiHgFCX U8KE4wrLKHz/BQ1BZkpOMnWsi4ZEMrKFNHMfGBNm6tk78uN4+Phd5jSKvXPPa5Rsd9no oXfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UYZIsh0NrSOQDrd1JqthCzGP2fby/uTg5ByP/XdrwnY=; b=pRf4Hi99WwznlJcRQL04EmsPTRZ2rk97V1cqf5aPgVQ3ZM2hasCtndTa5nupmbdGPg fgkq/6nlX12zMjPK/Ss8xP+VXfjet2TlhT1kBtSep1st2t8NhuAmsNCbbbYULluItWrv cJPFm+xEdbGV8zUNBLFHijoYrhBnApdsQktyALKwKiv3aDdDOu92aSpW3pLBshCKV6S6 IymIUaP9HUYuLdJodV0cYabLBnZ+wxZxZrdfgnfkEGkcTjn/eh9mGACQYhFGuKOwuPjo fZAYao59pF572gXB0wVEVP12WDjoPAhNFhjtItagqQVBNESsLPJ+GhzxQW9g9t4pmWbv MF5w== X-Gm-Message-State: AOAM533U5lkIpbMDbnmaaS6BX2g1Fgnq7yjXKh+d2DnWWcy5NqzlCxZB YEzV2EfLwrFkDjCDGxCkGg/lnMOhcfiH31xR7v4cQQ== X-Google-Smtp-Source: ABdhPJwBOvf89hk1DBDphHFMTgZcicZTVa7flVBS0X29K6sFOuEJhRf9TX/6Sh8sY221wKWRsnPqynTIRqck1vMEkt4= X-Received: by 2002:a17:906:5ac2:: with SMTP id x2mr2528113ejs.486.1614202847958; Wed, 24 Feb 2021 13:40:47 -0800 (PST) MIME-Version: 1.0 References: <3ddc0595-c443-868e-c0a4-08ae8934f116@flygoat.com> In-Reply-To: <3ddc0595-c443-868e-c0a4-08ae8934f116@flygoat.com> From: Jim Wilson Date: Wed, 24 Feb 2021 13:40:37 -0800 Message-ID: Subject: Re: HELP: MIPS PC Relative Addressing To: Jiaxun Yang Cc: "open list:MIPS" , Binutils , GCC Development , mfortune@gmail.com, syq@debian.org X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 21:40:52 -0000 On Wed, Feb 24, 2021 at 6:18 AM Jiaxun Yang wrote: > I found it's very difficult for GCC to generate this kind of pcrel_lo > expression, > RTX label_ref can't be lower into such LOW_SUM expression. > Yes, it is difficult. You need to generate a label, and put the label number in an unspec in the auipc pattern, and then create a label_ref to put in the addi. The fact that we have an unspec and a label_ref means a number of optimizations get disabled, like basic block duplication and loop unrolling, because they can't make a copy of an instruction that uses a label as data, as they have no way to know how to duplicate the label itself. Or at least RISC-V needs to create one label. You probably need to create two labels. There is a far easier way to do this, which is to just emit an assembler macro, and let the assembler generate the labels and relocs. This is what the RISC-V GCC port does by default. This prevents some optimizations like scheduling the two instructions, but enables some other optimizations like loop unrolling. So it is a tossup. Sometimes we get better code with the assembler macro, and sometimes we get better code by emitting the auipc and addi separately. The RISC-V gcc port can emit the auipc/addi with -mexplicit-relocs -mcode-model=medany, but this is known to sometimes fail. The problem is that if you have an 8-byte variable with 8-byte alignment, and try to load it with 2 4-byte loads, gcc knows that offset+4 must be safe from overflow because the data is 8-byte aligned. However, when you use a pc-relative offset that is data address-code address, the offset is only as aligned as the code is. RISC-V has 2-byte instruction alignment with the C extension. So if you have offset+4 and offset is only 2-byte aligned, it is possible that offset+4 may overflow the add immediate field. The same thing can happen with 16-byte data that is 16-byte aligned, accessed with two 8-byte loads. There is no easy software solution. We just emit a linker error in that case as we can't do anything else. I think this would work better if auipc cleared some low bits of the result, in which case the pc-relative offset would have enough alignment to prevent overflow when adding small offsets, but it is far too late to change how the RISC-V auipc works. If it looks infeasible for GCC side, another option would be adding > RISC-V style > %pcrel_{hi,lo} modifier at assembler side. We can add another pair of > modifier > like %pcrel_paired_{hi,lo} to implement the behavior. Would it be a good > idea? > I wouldn't recommend following the RISC-V approach for the relocation. Jim