From: Ian Lance Taylor <iant@google.com>
To: Chris Lattner <clattner@apple.com>
Cc: Diego Novillo <dnovillo@google.com>,
GCC Mailing List <gcc@gcc.gnu.org>,
Kenneth Zadeck <zadeck@naturalbridge.com>,
Jan Hubicka <jh@suse.cz>,
Rafael Espindola <espindola@google.com>,
Ollie Wild <aaw@google.com>,
Robert Hundt <rhundt@google.com>,
Nick Kledzik <kledzik@apple.com>,
Devang Patel <dpatel@apple.com>
Subject: Re: [whopr] Design/implementation alternatives for the driver and WPA
Date: Wed, 04 Jun 2008 19:45:00 -0000 [thread overview]
Message-ID: <m3wsl50yun.fsf@google.com> (raw)
In-Reply-To: <D054C487-3C4A-4BCB-A27A-513412B5837E@apple.com> (Chris Lattner's message of "Wed\, 4 Jun 2008 09\:29\:07 -0700")
Chris Lattner <clattner@apple.com> writes:
>> * The return value of lto_module_get_symbol_attributes is not
>> defined.
>
> Ah, sorry about that. Most of the details are actually in the public
> header. The result of this function is a 'lto_symbol_attributes'
> bitmask. This should be more useful and revealing:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/lto.h?revision=HEAD&view=markup
From an ELF perspective, this doesn't seem to have a way to indicate a
common symbol, and it doesn't provide the symbol's type. It also
doesn't have a way to indicate section groups.
(How do section groups work in Mach-O? Example is a C++ template
function with a static constant array which winds up in the .rodata
section. Section groups permit discarding the array when we discard
the function code.)
>> * Interfaces like lto_module_get_symbol_name and
>> lto_codegen_add_must_preserve_symbol are inefficient when dealing
>> with large symbol tables.
>
> The intended model is for the linker to query the LTO plugin for its
> symbol list and build up its own linker-specific hash table. This way
> you don't need to force the linker to use the plugin's data structure
> or the plugin to use the linker data structure. We converged on this
> approach after trying it the other way.
>
> Does this make sense, do you have a better idea?
In gcc's LTO approach, I think the linker will already have access to
the symbol table anyhow. But my actual point here is that requiring a
function call for every symbol is inefficient. These functions should
take an array and a count. There can be hundreds of thousands of
entries in a symbol table, and the interface should scale accordingly.
>> The LLVM
>> interface does not do that.
>
> Yes it does, the linker fully handles symbol resolution in our model.
>
>> Suppose the linker is invoked on a
>> sequence of object files, some with with LTO information, some
>> without, all interspersed. Suppose some symbols are defined in
>> multiple .o files, through the use of common symbols, weak symbols,
>> and/or section groups. The LLVM interface simply passes each object
>> file to the plugin.
>
> No, the native linker handles all the native .o files.
>
>> The result is that the plugin is required to do
>> symbol resolution itself. This 1) loses one of the benefits of having
>> the linker around; 2) will yield incorrect results when some non-LTO
>> object is linked in between LTO objects but redefines some earlier
>> weak symbol.
>
> In the LLVM LTO model, the plugin only needs to know about its .o
> files, and the linker uses this information to reason about symbol
> merging etc. The Mac OS X linker can even do dead code stripping
> across Macho .o files and LLVM .bc files.
To be clear, when I said object file here, I meant any input file.
You may have understood that.
In ELF you have to think about symbol overriding. Let's say you link
a.o b.o c.o. a.o has a reference to symbol S. b.o has a strong
definition. c.o has a weak definition. a.o and c.o have LTO
information, b.o does not. ELF requires that a.o call the symbol from
b.o, not the symbol from c.o. I don't see how to make that work with
the LLVM interface.
This is not a particularly likely example, of course. People rely on
this sort of symbol overriding quite a bit, but it's unlikely that a.o
and c.o would have LTO information while b.o would not. However,
given that we are designing an interface, I think we should design it
so that correctness is possible.
> Further other pieces of the toolchain (nm, ar, etc) also use the same
> interface so that they can return useful information about LLVM LTO
> files.
Useful, but as I understand it gcc's LTO files will have that
information anyhow.
> This is our second major revision of the LTO interfaces, and the
> interface continues to slowly evolve. I think it would be great to
> work with you guys to extend the design to support GCC's needs.
Agreed.
Ian
next prev parent reply other threads:[~2008-06-04 19:45 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-03 16:46 Diego Novillo
2008-06-04 2:27 ` Chris Lattner
2008-06-04 7:28 ` Rafael Espindola
2008-06-04 16:34 ` Chris Lattner
2008-06-04 16:48 ` Rafael Espindola
2008-06-04 13:00 ` Diego Novillo
2008-06-04 15:28 ` Kenneth Zadeck
2008-06-04 15:54 ` Ian Lance Taylor
2008-06-04 16:50 ` Kenneth Zadeck
2008-06-04 17:05 ` Diego Novillo
2008-06-04 17:37 ` Ian Lance Taylor
2008-06-04 16:15 ` Chris Lattner
[not found] ` <65dd6fd50806041223l1871ecfbh384aa175c3da0645@mail.gmail.com>
2008-06-04 19:30 ` Fwd: " Ollie Wild
[not found] ` <89069638-6D2B-4AE6-ACB3-99A2B09091BA@apple.com>
2008-06-04 20:02 ` Ollie Wild
2008-06-04 23:59 ` Diego Novillo
2008-06-04 20:03 ` Kenneth Zadeck
2008-06-04 20:30 ` Ian Lance Taylor
2008-06-04 20:56 ` Diego Novillo
2008-06-05 15:10 ` Jan Hubicka
2008-06-05 15:23 ` Diego Novillo
2008-06-04 14:28 ` Ian Lance Taylor
2008-06-04 16:29 ` Chris Lattner
2008-06-04 16:41 ` Chris Lattner
2008-06-04 18:48 ` Devang Patel
2008-06-04 19:45 ` Ian Lance Taylor [this message]
2008-06-04 20:38 ` Nick Kledzik
2008-06-04 20:46 ` Ian Lance Taylor
2008-06-04 21:43 ` Nick Kledzik
2008-06-05 0:01 ` Ian Lance Taylor
2008-06-05 0:20 ` Nick Kledzik
2008-06-05 0:43 ` Ian Lance Taylor
2008-06-05 1:09 ` Nick Kledzik
2008-06-05 5:07 ` Devang Patel
2008-06-05 5:43 ` Ian Lance Taylor
2008-06-05 6:09 ` [whopr] plugin interface design Chris Lattner
2008-06-05 13:53 ` Ian Lance Taylor
2008-06-05 16:37 ` Chris Lattner
2008-06-05 17:39 ` Ian Lance Taylor
2008-06-07 18:31 ` Chris Lattner
2008-06-05 5:44 ` [whopr] Design/implementation alternatives for the driver and WPA Ian Lance Taylor
2008-06-05 8:41 ` Rafael Espindola
2008-06-05 14:00 ` Ian Lance Taylor
2008-06-05 16:44 ` Chris Lattner
2008-06-05 17:44 ` Ian Lance Taylor
2008-06-05 18:50 ` Nick Kledzik
2008-06-05 21:03 ` Ian Lance Taylor
2008-06-05 21:47 ` Chris Lattner
2008-06-06 1:22 ` Ian Lance Taylor
2008-06-07 18:34 ` Chris Lattner
[not found] ` <65dd6fd50806032310u2bda0953qb911e3ccfe3f305e@mail.gmail.com>
2008-06-04 19:29 ` Fwd: " Ollie Wild
2008-06-04 14:45 ` Ian Lance Taylor
2008-06-04 14:48 ` Diego Novillo
2008-06-04 15:28 ` Rafael Espindola
2008-06-04 16:31 ` Mark Mitchell
2008-07-04 3:31 ` Cary Coutant
2008-07-04 6:28 ` Ian Lance Taylor
2008-07-04 22:58 ` Daniel Jacobowitz
2008-07-06 7:30 ` Cary Coutant
2008-07-07 6:13 ` Ian Lance Taylor
2008-07-04 13:43 ` Rafael Espindola
2008-07-06 14:22 ` Cary Coutant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3wsl50yun.fsf@google.com \
--to=iant@google.com \
--cc=aaw@google.com \
--cc=clattner@apple.com \
--cc=dnovillo@google.com \
--cc=dpatel@apple.com \
--cc=espindola@google.com \
--cc=gcc@gcc.gnu.org \
--cc=jh@suse.cz \
--cc=kledzik@apple.com \
--cc=rhundt@google.com \
--cc=zadeck@naturalbridge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).