* End of first pass may be a little gold specific. Perhaps it
should be called something like after all input files have been
seen.
Sure. It seems to me that the pass 1, middle, pass 2 breakdown is
pretty common for linkers, though perhaps not universal. I'll find a
better name (I wasn't
On the claim file, can you also pass the file size in the case it
is inside an archive?
Good idea. Will do.
-cary
Cary Coutant [EMAIL PROTECTED] writes:
* GOLD_VERSION should perhaps say something about the format of the
string.
OK. What would be reasonable to say here? Just a string of the form
n.m? Is it reasonable to require that later versions are lexically
greater than earlier versions (e.g.,
I've updated the WHOPR Driver wiki page with our latest thoughts on
the plug-in interface:
http://gcc.gnu.org/wiki/whopr/driver
Very nice! Just one comment:
On the claim file, can you also pass the file size in the case it
is inside an archive?
-cary
Cheers,
--
Rafael Avila de
On Thu, Jul 03, 2008 at 09:48:11PM -0700, Ian Lance Taylor wrote:
* The linker does normally copy unrecognized sections with the
SHF_ALLOC bit clear to the output file. It doesn't allocate address
space for them, but it does copy them. I think this follows the ELF
ABI. I don't know of
We've started working on the driver and WPA components for whopr.
These are some of our initial thoughts and implementation strategy. I
have linked these to the WHOPR page as well. I'm hoping we can
discuss these at the Summit BoF, so I'm posting them now to start the
discussion.
I've
Cary Coutant [EMAIL PROTECTED] writes:
We've started working on the driver and WPA components for whopr.
These are some of our initial thoughts and implementation strategy. I
have linked these to the WHOPR page as well. I'm hoping we can
discuss these at the Summit BoF, so I'm posting them
On Jun 5, 2008, at 6:18 PM, Ian Lance Taylor wrote:
How does the linker tell LTO that a symbol may be inlined, but
must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO
engine
is free to inline anything that would improve codegen, with the
exception
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
Rafael Espindola [EMAIL PROTECTED] writes:
Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
of the opposite of what I had understood. What do you do in this case:
a.o: IL file that contains a reference to f
b.o: IL file that has a weak def of f
There is no strong
Hi,
I am jumping in somewhat late, as yesterday I was on meetings without
internet access. (and I probably will be offline again tomorrow)
I think that in basic terms we all mostly agree (we want to implement
optimization scheme that does not get everything into memory, we want to
parallelize the
On Thu, Jun 5, 2008 at 11:09, Jan Hubicka [EMAIL PROTECTED] wrote:
I think one problem is that both repackaging and cherry picking as
described is very centric about application on inlining.
No, that's simply the main application for the initial implementation.
Any other summary-based
On Jun 5, 2008, at 6:59 AM, Ian Lance Taylor wrote:
Rafael Espindola [EMAIL PROTECTED] writes:
Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
of the opposite of what I had understood. What do you do in this
case:
a.o: IL file that contains a reference to f
b.o: IL
Chris Lattner [EMAIL PROTECTED] writes:
LLVM LTO handles this by marking symbols internal (aka static, aka
not TREE_PUBLIC, whatever) when the symbol is not visible outside the
LTO scope. This allows the optimizers to go crazy and hack away at
the symbols, but only when safe.
How does the
On Jun 5, 2008, at 10:43 AM, Ian Lance Taylor wrote:
Chris Lattner [EMAIL PROTECTED] writes:
LLVM LTO handles this by marking symbols internal (aka static, aka
not TREE_PUBLIC, whatever) when the symbol is not visible outside the
LTO scope. This allows the optimizers to go crazy and hack
Nick Kledzik [EMAIL PROTECTED] writes:
How does the linker tell LTO that a symbol may be inlined, but must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO engine
is free to inline anything that would improve codegen, with the
exception
that any weak
On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote:
Nick Kledzik [EMAIL PROTECTED] writes:
How does the linker tell LTO that a symbol may be inlined, but must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO engine
is free to inline anything that
Chris Lattner [EMAIL PROTECTED] writes:
On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote:
Nick Kledzik [EMAIL PROTECTED] writes:
How does the linker tell LTO that a symbol may be inlined, but must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO
Is there a specific reason you don't use the LLVM LTO interface? It seems
to be roughly the same as your proposed interface:
a) it has a simple C interface like your proposed one
b) it is already implemented in one system linker (Apple's), so GCC would
just provide its own linker plugin and
On Tue, Jun 3, 2008 at 22:26, Chris Lattner [EMAIL PROTECTED] wrote:
and whopr here. Is LTO the mode normal people will use, and whopr is the
mode where people with huge clusters will use? Will LTO/whopr support
useful optimization on common multicore machines?
As Ollie said, WHOPR is just
Chris Lattner [EMAIL PROTECTED] writes:
Is there a specific reason you don't use the LLVM LTO interface? It
seems to be roughly the same as your proposed interface:
a) it has a simple C interface like your proposed one
b) it is already implemented in one system linker (Apple's), so GCC
Diego Novillo [EMAIL PROTECTED] writes:
I have a feeling that the comments I wrote within Google about the
linker interface were lost. I am going to try to recreate them here.
The linker, upon start, examines a configuration file at a known
location relative to its own location. If this file
On Wed, Jun 4, 2008 at 10:44, Ian Lance Taylor [EMAIL PROTECTED] wrote:
I have a feeling that the comments I wrote within Google about the
linker interface were lost. I am going to try to recreate them here.
Sorry. I should've been more careful when I transcribed it over.
Diego.
Diego Novillo wrote:
On Tue, Jun 3, 2008 at 22:26, Chris Lattner [EMAIL PROTECTED] wrote:
and whopr here. Is LTO the mode normal people will use, and whopr is the
mode where people with huge clusters will use? Will LTO/whopr support
useful optimization on common multicore machines?
2008/6/4 Ian Lance Taylor [EMAIL PROTECTED]:
Diego Novillo [EMAIL PROTECTED] writes:
I have a feeling that the comments I wrote within Google about the
linker interface were lost. I am going to try to recreate them here.
I have added them to the gcc wiki.
I have also removed some of the
Kenneth Zadeck [EMAIL PROTECTED] writes:
I think that one thing that the gcc community should understand is
that to a great extent whopr is a google thing. All of the documents
are drafted by google people, in meetings that are only open to google
people and it is only after these documents
On Jun 4, 2008, at 8:27 AM, Kenneth Zadeck wrote:
It is certainly not going to be possible to do this for all ipa
passes, in particular any pass that requires the function body to be
reanalyzed as part of the analysis pass will not be done, or will be
degraded so that it does not use this
On Jun 4, 2008, at 7:22 AM, Ian Lance Taylor wrote:
Chris Lattner [EMAIL PROTECTED] writes:
Is there a specific reason you don't use the LLVM LTO interface? It
seems to be roughly the same as your proposed interface:
a) it has a simple C interface like your proposed one
b) it is already
Diego Novillo wrote:
We've started working on the driver and WPA components for whopr.
These are some of our initial thoughts and implementation strategy. I
have linked these to the WHOPR page as well. I'm hoping we can
discuss these at the Summit BoF, so I'm posting them now to start the
On Jun 4, 2008, at 12:27 AM, Rafael Espindola wrote:
Is there a specific reason you don't use the LLVM LTO interface?
It seems
to be roughly the same as your proposed interface:
a) it has a simple C interface like your proposed one
b) it is already implemented in one system linker
On Jun 4, 2008, at 9:29 AM, Chris Lattner wrote:
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
Hey Rafael!
Hello!
*) Plugins could have other uses and the naming used on the LLVM LTO
interface is LTO specific.
The LLVM interface uses an lto_ prefix. This interface is used by nm/ar/etc
as well as the linker. Is there something specific about lto_ that is bad?
Ian Lance Taylor wrote:
Kenneth Zadeck [EMAIL PROTECTED] writes:
I think that one thing that the gcc community should understand is
that to a great extent whopr is a google thing. All of the documents
are drafted by google people, in meetings that are only open to google
people and it is
On Wed, Jun 4, 2008 at 12:50, Kenneth Zadeck [EMAIL PROTECTED] wrote:
While i agree that some form of lto needs to support monster apps, that
should not inhibit us from supporting transformations or models of
compilation that are only practical with 100k line programs.
Of course not. That
Kenneth Zadeck [EMAIL PROTECTED] writes:
In particular, there are a lot of decisions that are being made in
whopr to support very large applications that are done so at the
expense of compiling modest and even large applications. I do not
necessarily disagree with these decisions, but I
Also, returning a single object file restricts the possibilities.
The
design of WHOPR, as I understand it, permits creating several
different object files in parallel based on a fast analysis of which
code should be compiled together. When the linker supports
concurrent
linking, it will be
Reposting to the gcc list since my first email got bounced.
Ollie
On Tue, Jun 3, 2008 at 7:26 PM, Chris Lattner [EMAIL PROTECTED] wrote:
This is a very interesting design, and a very nice evolution from the
previous proposal. I'm not completely clear on the difference between LTO
and
Reposting this as well.
Ollie
On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner [EMAIL PROTECTED] wrote:
1) start with all code in memory and see how far you can get. It seems that
on reasonable developer machines (e.g. 2GB memory) that we can handle C
programs on the order of a million
Chris Lattner [EMAIL PROTECTED] 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
On Wed, Jun 4, 2008 at 12:33 PM, Chris Lattner [EMAIL PROTECTED] wrote:
Right, I understand that you design stacks on LTO. It just seems strange
to work on the advanced stuff before the basic GCC LTO stuff is close to
being useful.
To some degree, we're scratching our own itch here. Basic
Ollie Wild wrote:
On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
1) start with all code in memory and see how far you can get. It
seems that on reasonable developer machines (e.g. 2GB memory) that
we can handle C programs on the
Kenneth Zadeck [EMAIL PROTECTED] writes:
I do not want to imply that google's needs are not real and that they
should not use gcc to fulfill them. I only want to raise the point
that whopr is at one end of a spectrum in which REAL tradeoffs are
being made in the quality of compilation vs
On Jun 4, 2008, at 12:44 PM, Ian Lance Taylor wrote:
Chris Lattner [EMAIL PROTECTED] 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
Nick Kledzik [EMAIL PROTECTED] writes:
On Jun 4, 2008, at 12:44 PM, Ian Lance Taylor wrote:
Chris Lattner [EMAIL PROTECTED] 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
On Wed, Jun 4, 2008 at 16:03, Kenneth Zadeck [EMAIL PROTECTED] wrote:
However this was not the point of my mail. The point of my mail was whopr's
design that seems to basically sacrifice almost all interprocedural analysis
and transformation except for inlining in order to scale so as to be
On Jun 4, 2008, at 1:45 PM, Ian Lance Taylor wrote:
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
On Wed, Jun 4, 2008 at 15:33, Chris Lattner [EMAIL PROTECTED] wrote:
Right, I understand that you design stacks on LTO. It just seems strange
to work on the advanced stuff before the basic GCC LTO stuff is close to
being useful.
Not at all. We are working on both fronts.
Diego.
Nick Kledzik [EMAIL PROTECTED] writes:
I don't claim our current implementation is bug free, but the lto
interface
matches the Apple linker internal model, so we don't expect and have
not encountered any problems mixing mach-o and llvm bitcode files.
Hmmm, OK, how about this example:
a.o:
On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote:
Nick Kledzik [EMAIL PROTECTED] writes:
I don't claim our current implementation is bug free, but the lto
interface
matches the Apple linker internal model, so we don't expect and have
not encountered any problems mixing mach-o and llvm
Nick Kledzik [EMAIL PROTECTED] writes:
On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote:
Nick Kledzik [EMAIL PROTECTED] writes:
I don't claim our current implementation is bug free, but the lto
interface
matches the Apple linker internal model, so we don't expect and have
not encountered
On Jun 4, 2008, at 5:39 PM, Ian Lance Taylor wrote:
Nick Kledzik [EMAIL PROTECTED] writes:
On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote:
Nick Kledzik [EMAIL PROTECTED] writes:
I don't claim our current implementation is bug free, but the lto
interface
matches the Apple linker
On Jun 4, 2008, at 6:09 PM, Nick Kledzik wrote:
On Jun 4, 2008, at 5:39 PM, Ian Lance Taylor wrote:
Nick Kledzik [EMAIL PROTECTED] writes:
On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote:
Nick Kledzik [EMAIL PROTECTED] writes:
I don't claim our current implementation is bug free, but
[ trimming the CC list ]
Devang Patel [EMAIL PROTECTED] writes:
If the optimizer can handle the symbol versioning case when one
definition with version is defined in the same source file as the
reference then you don't need new API.
For example,
a.o : refers to S and defines S at version
Nick Kledzik [EMAIL PROTECTED] writes:
In this case S is a regular symbol. So the previous trick won't
work. Probably
the best solution would be to add a new lto_ API to tell the LTO
engine to
ignore a definition is already has. It would make more sense to use
this
new API in the weak
We've started working on the driver and WPA components for whopr.
These are some of our initial thoughts and implementation strategy. I
have linked these to the WHOPR page as well. I'm hoping we can
discuss these at the Summit BoF, so I'm posting them now to start the
discussion.
Robert, Ollie,
On Jun 3, 2008, at 9:45 AM, Diego Novillo wrote:
We've started working on the driver and WPA components for whopr.
These are some of our initial thoughts and implementation strategy. I
have linked these to the WHOPR page as well. I'm hoping we can
discuss these at the Summit BoF, so I'm
56 matches
Mail list logo
