From owner-svn-src-head@freebsd.org Thu Sep 17 17:25:58 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D174A3E7F8D for ; Thu, 17 Sep 2020 17:25:58 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BskQF5yslz4Kdy for ; Thu, 17 Sep 2020 17:25:57 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: by mail-wm1-f49.google.com with SMTP id w2so2729239wmi.1 for ; Thu, 17 Sep 2020 10:25:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=opux/o8U6Vm/T6AdMEBFhu/RZw/mcvm17dTHNLgYL10=; b=HE5/FPzjnv22Oa7OogbbLf3tyZCtN2ETe5JxSUSl60BndKV36lc0NlIWP61VuUbDEa 063JGNqeEP1QRwSeyJEM9EpNQfgE+aXry+D6XULkie+uQO4T/UOG6j+iXplrjj0iTH4N /9yiDEyskrBO+ZH1LOfLwS1MJyTveXI3G1W3u293qSm3I9AfezcATntyrg6tAi/FdGOZ 0yrNuAIaYDMKb85T3+oxu39+VlnZJKov6xveEtxNN/46mXAcurueuNoRaAXQkfT+ctLC 99eyftkODJXtJ0jN1ojAzY3dQrKEgbtLqvNYWzLoXzbim6vseRnFQeNG2fiSgFqIUOdc Y5GA== X-Gm-Message-State: AOAM533IFaNXfCMg60widVnCrXWV+5C4c5P+YgiwCAcyxqMgBk3IO2/f z9CI+fI2bzAGQQ/ZVfTABQSPtg== X-Google-Smtp-Source: ABdhPJwPB3PtzDR3lhcSa0wAZX4UVppGZv8pR0e4/QHKJCL4hQ7+ngR5z/PKT43GjaF8GD4t3H12cw== X-Received: by 2002:a05:600c:4108:: with SMTP id j8mr9645370wmi.116.1600363556377; Thu, 17 Sep 2020 10:25:56 -0700 (PDT) Received: from [192.168.149.251] (trinity-students-nat.trin.cam.ac.uk. [131.111.193.104]) by smtp.gmail.com with ESMTPSA id u17sm260826wmm.4.2020.09.17.10.25.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Sep 2020 10:25:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: svn commit: r365836 - head/share/mk From: Jessica Clarke In-Reply-To: Date: Thu, 17 Sep 2020 18:25:55 +0100 Cc: Warner Losh , Alex Richardson , src-committers , svn-src-all , svn-src-head Content-Transfer-Encoding: quoted-printable Message-Id: <307760E0-1208-4F4C-AD7D-9E0A3C1B3A3B@freebsd.org> References: <202009171705.08HH5CtE014644@gndrsh.dnsmgr.net> To: rgrimes@freebsd.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4BskQF5yslz4Kdy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jrtc27@jrtc27.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com X-Spamd-Result: default: False [-1.77 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.27)[-0.270]; FORGED_SENDER(0.30)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.958]; FREEFALL_USER(0.00)[jrtc27]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.039]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.49:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.49:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[svn-src-head] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 17:25:58 -0000 > On 17 Sep 2020, at 18:23, Jessica Clarke wrote: >=20 >> On 17 Sep 2020, at 18:05, Rodney W. Grimes = wrote: >>=20 >>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso = wrote: >>>=20 >>>> Alex Richardson wrote in >>>> <202009171507.08HF7Qns080555@repo.freebsd.org>: >>>> |Author: arichardson >>>> |Date: Thu Sep 17 15:07:25 2020 >>>> |New Revision: 365836 >>>> |URL: https://svnweb.freebsd.org/changeset/base/365836 >>>> | >>>> |Log: >>>> | Stop using lorder and ranlib when building libraries >>>> | >>>> | Use of ranlib or lorder is no longer necessary with current = linkers >>>> | (probably anything newer than ~1990) and ar's ability to create = an >>>> object >>>> | index and symbol table in the archive. >>>> | Currently the build system uses lorder+tsort to sort the .o = files in >>>> | dependency order so that a single-pass linker can use them. = However, >>>> | we can use the -s flag to ar to add an index to the .a file = which makes >>>> | lorder unnecessary. >>>> | Running ar -s is equivalent to running ranlib afterwards, so we = can >>>> also >>>> | skip the ranlib invocation. >>>>=20 >>>> That ranlib thing yes (for long indeed), but i have vague memories >>>> that the tsort/lorder ordering was also meant to keep the things >>>> which heavily interdepend nearby each other. (Luckily Linux >>>> always had at least tsort available.) >>>> This no longer matters for all the platforms FreeBSD supports? >>>>=20 >>>=20 >>> tsort has no notion of how dependent the modules are, just an order = that >>> allows a single pass through the .a file (otherwise you'd need to = list the >>> .a file multiple times on the command line absent ranlib). That's = the >>> original purpose of tsort. tsort, lsort, and ranlib all arrived in = 7th >>> edition unix on a PDP-11, where size was more important than = proximity to >>> locations (modulo overlays, which this doesn't affect at all). >>>=20 >>> There were some issues of long vs short jumps on earlier = architectures that >>> this helped (since you could only jump 16MB, for example). However, = there >>> were workarounds for this issue on those platforms too. And if you = have a >>> program that this does make a difference, then you can still use >>> tsort/lorder. They are still in the system. >>>=20 >>> I doubt you could measure a difference here today. I doubt, = honestly, that >>> anybody will notice at all. >>=20 >> The x86 archicture has relative jmps of differning lengths, even in = long mode >> there is support for rel8 and rel32. >=20 > That's irrelevant though for several reasons: >=20 > 1. The compiler has already decided on what jump instructions to use = based on > the requested code model (unless you're on RISC-V and using GNU bfd = ld as > that supports linker relaxations that actually delete instruction = bytes). >=20 > 2. The linker is still free to reorder input sections however it = likes, it > doesn't have to follow the order of the input files (and the files = within > any archive). Hm actually that's only true for archives; it needs to respect the order = of files on the command line for things like crti.o to work. But = regardless, the other points (and this one, partially) still hold. > 3. If you care about those kinds of optimisations you should use = link-time > optimisation which will likely do far more useful things than just = optimise > branches, but again isn't constrained by the order of the input = files, it > can lay out the code exactly how it wants. >=20 > Not to mention that this is just a topological sort, not a clustering = sort. >=20 > Jess