From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 65B553858C53 for ; Wed, 13 Apr 2022 18:11:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 65B553858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pg1-x52d.google.com with SMTP id t13so2502881pgn.8 for ; Wed, 13 Apr 2022 11:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=4zCk2inG+qXR6FY+32osuyiGLHkczRz5k4UaEa0g5rQ=; b=07voTozlLhB3rrOPI98ZAmNHUxAsRFtjhrPADX7xPBJVeT1tcCJz4wgUvkHeJomVWT 7eoLNIyUPv3/m/ILX8JuB3B05UORzVmUzHpf8WJVuR3fFnYIiLyt8JrqsyOblq1guqbq WJ3ng9ybCO57HHCJnktDG88WvkEhrw5+7DzP+FCqLoSbOeIToCTnFILa4IJi3FQQ+uXT Uvdx/jVV0xqID23Ckls7usU3HaK3ub7qws8eIxsgVQjUu+znb4/e6f5/UF1WOBaaXAml G+2fR7EDKx6CN4AkBjTNbK52/WB1Z+W3OLx5+Fd9yYNlXIrDZc4062mpZ5YTLRyVaWqk kN1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=4zCk2inG+qXR6FY+32osuyiGLHkczRz5k4UaEa0g5rQ=; b=BXP8BRAkH4w5TVlHwE97ShKJwkdJbYugMZJmMSJsJ1XMoAiY/ZqAUnuG96LG2y5ymt +69k/Srkv1rahBG0YwO1rQTJZhxJ7GWUZCeWWsVfzlEb2QUgx/PI5LKVMEKxIHGyCQ5d 3tvmw1MMJN3+eHCYtMT+zupKzU/XmSBS2x3pGGom+EJ0eDOzAyNlhkeE/l9pK9W4SiJi g+03z7OnKdGdjrDEMrhuFrDrtDBHlXVN7+iSwsw02uOI1gDvpI8qGlPXYnsW9Dvl1fE0 MXrlNsQFc9d9J9jp2C5DS/TJlrO9BHOQ/u0BBqCTT8RWZTNx/4rFyJOj6xRSBMWheCgZ T/cw== X-Gm-Message-State: AOAM5322Cz9Z+jNI/E98QxGuiSo6v+EI3T/NacrUbFqWp8m/iSGemrKY XzKPN2B3eswC2/bXrJ3lquVL8RTGvGOiIQ== X-Google-Smtp-Source: ABdhPJx+7g+8xUHRoscTeb4USZhVjr0IfBmrXTpnbbuUhCIqxuEaSsznPDPqFgWyhOb/iONots99XQ== X-Received: by 2002:a63:40c7:0:b0:39d:8c29:2f57 with SMTP id n190-20020a6340c7000000b0039d8c292f57mr8966135pga.202.1649873493140; Wed, 13 Apr 2022 11:11:33 -0700 (PDT) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id p10-20020a056a0026ca00b004fb44e0cb17sm43981011pfw.116.2022.04.13.11.11.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 11:11:31 -0700 (PDT) Date: Wed, 13 Apr 2022 11:11:31 -0700 (PDT) X-Google-Original-Date: Wed, 13 Apr 2022 11:11:29 PDT (-0700) Subject: Re: [PATCH 0/4] RISCV: Improve linker time complexity In-Reply-To: CC: Kito Cheng , Patrick O'Neill , binutils@sourceware.org, gnu-toolchain@rivosinc.com From: Palmer Dabbelt To: binutils@sourceware.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 18:11:37 -0000 On Tue, 12 Apr 2022 22:12:22 PDT (-0700), binutils@sourceware.org wrote: > On Wed, Apr 13, 2022 at 08:58:38AM +0800, Kito Cheng via Binutils wrote: >> And I have a suggestion here is - does it possible to let co-exist with current >> implementation and having a command line option to select the linker >> relaxation, of course we >> could default to using the new implementation, but that gives us an >> emergency fallback option to use the old implementation :) > > You already have an emergency fallback, use an older binutils or > revert the patchset. IMO you do not want two implementations of any > given feature. Doing so just makes it more likely that neither > implementation is good. IMO a key point here is that the hueristics are subtly different, the linear-time algorithm will fail at both forwards and backwards targets where relaxation enables relaxation (as opposed to just failing at the forwards targets, like the old one did). The theory is that there aren't any pathological cases in the wild, but it's hard to know for sure. I think it should just be a few lines of code to match the old behavior (ie, just eagerly delete instead of deferring it to after all relocations are processed), but I'm not sure -- the change around alignment handling is tripping me up, as that was unexpected on my end. That said, there's certainly enough complexity here so I don't think it's a big deal to just only support the new flavor.