From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8E6CB386F457; Wed, 24 Jun 2020 00:07:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E6CB386F457 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1592957228; bh=WchZw3YovB20lIAlsHTwBI/9pk6nHNR/t593Dfi0WAM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nSEbIyxBXr58Ve7bRrcSOEcKpct3NrLuczybNFE98l7oIcaoNDH1jsQx5dnWwjpZp TIS1Rww+HV7q41zsn5CZn7on6FCbGDfIiAMK7/jmM3SSjuVzlZQR6iU2gB2qyJ85Tg MKlTuM43DSgO7Gfq/juh5MzgmO8GqxAt/6vT5PFs= From: "yyc1992 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/95775] Command line argument for target_clones? Date: Wed, 24 Jun 2020 00:07:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.1.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: yyc1992 at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 00:07:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95775 --- Comment #4 from Yichao Yu --- > Hey. My opinion is similar to Richi's. If you really want a highly optimi= zed library, you should rather use a dlopen mechanism with pre-built set of= options. Well, a few things, 1. That sounds like an argument against `target_clone` and `target`. If dlopen'ing different libraries is your recommended solution then none of th= ese would be needed. 2. The solution you propose put all the pression on the user of the library. That has a few problems. 2.1. There are strictly more users than libraries. (Assuming the library= is used at all) so this is forcing more (repeated) work to be done. 2.2. The author of the library and to a lesser degree the builder of the library has the best knowledge of the set of features that can benefit the library/the most useful for the deployment environment. The author of the u= ser code of the library, who has to implement the dispatch/loading logic in gen= eral has much less complete knowledge of what the target to support. 2.3. It'll be even worse for code size since this forces each user to ca= rry their own library, and now all data has to be duplicated as well in additio= nal to code. Also because, 3. There's no standard way of doing this AFAICT. Now (3) is really the main point. I'm fine with whatever mechanism that allows multiple versions of the code = to be available as long as it requires no more effort/cost from/for the user (= and to a lesser degree the author) of the library. If one such mechanism is provided by gcc/glibc/binutils so that library wri= ters don't have to invent their own loading and detection mechanism and won't ca= use unnecessary indirection (as cheap as ifunc) and will just work for the user= to either link or dlopen, then I think it doesn't really matter if that's back= ed by one file/multiple files or whatever one can come up with. Currently, the only mechanism available that fits this description AFAICT is `target_clones`/`ifunc`. Unless there's a roadmap that I'm not aware of to replace this mechanism with a similar one backed by multiple files I don't think suggesting such a mechanism is the right approach. Again, I said in the very first post that I totally agree this won't be the method to give absolutely the best performance, but neither is `target_clon= es`. I also completely agree that this option can be misused and the compiler sh= ould not do it on its own before getting smarter but this is far from the first option that can be misused and given how cheap memory is and how multiple l= oad of the same library doesn't take more memory this isn't even closoed to be = the worse misused either.=